What’s in the Metrics?

Agile contains a multitude of methodologies, but using a cumulative flow design might be the great unifier you’ve been looking for.

Everyone’s supervisor wants to know the metrics behind their Agile journey.

Some of the most frequently-asked questions during Agile Scrum training are:

• “There are a lot of metrics to measure. Which one I should pick up to track the progress of my team?”
• “I use both the methodologies Scrum & Kanban within our iterations and I don’t want to confuse my team members with different metrics from time to ntime.”
• “I thought my daily stand-ups are effective, but many times the last-minute spill-over surprises me.”
• “My manager keeps telling me constantly to “raise the bar” to build a high-performing team. I am not even sure where we are today to consider the next level”

Scrum espouses principles of “transparency, inspection, adaption,” Kanban’s philosophy involves “visualization, limiting WIP & enhancing flow,” and Extreme Programming values “communication, simplicity & feedback.” But the common theme revolves around visibility of work inclusive of blockers for the team, not only to understand where we are but also to do course correction.

Throughput and cycle time of the deliverables are two vital parameters to understand the progress as well as the projection of completion based on the current timeline.

While there are different charts and measurements that help in understanding throughput and cycle time – burn-up or burn-down in Scrum, visual flow in Kanban, velocity in extreme programming – cumulative flow diagram is one powerful chart that works effectively irrespective of the Agile methodologies the team operates in.

“The greatest value of a picture is when it forces us to notice what we never expected to see.” – John W. Tukey

Let me explain the power of a cumulative flow diagram as compared to other charts in understanding the flow better for actionable outcomes.

Below is the summary of the work planned and achieved by the team over 10 days:

Let us explore a simple burn-down chart that depicts the ideal work remaining vs. actual work remaining:

Burn-down helps in understanding if we are on target or behind in comparison with ideal work remaining. It doesn’t directly reflect the change though.

Now, let us the same through burn-up chart:

While this also helps in understanding work remaining, we can see the change in scope after Day-5.

Both the burn-up and burn-down charts focus on work completed and work remaining from customer perspective. While these are great measures, we also need to understand the intermediate flow (movement from one state to another) to be able to understand blockers and impediments.

Let us represent the above with a simple stacked bar chart:

Much better, isn’t it? This depicts the progress through various stages as well as the scope change (the spike on Day 6).

It’s time to covert the stacked bar chart into stacked area chart.

Bingo! Here comes our superhero cumulative flow diagram to our rescue to be able to deep dive further. Each colored area represents the flow (in the above, it is “Yet to Start”, “In Progress”, “Done,” and “Shipped”) and shift from one to another depicts throughput.

There are several important key takeaways from this chart which helps in further inspection & adaption:

• Scope Change: Change in overall horizontal line. In the above chart, the change occurred on Day 6 and is stable after that.
• Thin Flow: Thin flow represents a quicker process. “Done” flow is faster compared to “In Progress”. If we need to lean overall throughput, then our focus should be on the “In Progress” flow.
• Average Lead Time: The horizontal shift from “Yet to Start” to “Shipped”
• Cycle Time: The horizontal shift from one state to another. For example, “In Progress” to “Done” will provide the cycle time.
• WIP: It’s important to measure the work-in-progress since limiting WIP expedites the progress. The vertical line within one state provides the number of items that are being processed (a.k.a) WIP.

It’s a myth that the cumulative flow diagram is only for Kanban methodology. It provides immense value across the board. Cumulative flow diagram can be plotted for stories/tasks within an iteration. Hence is a great value addition in Scrum as well. It can also be expanded for features at program level and epics at the portfolio level. Thus, it provides benefits at various persona levels: Scrum master, program manager, product manager and business stakeholders. This is applicable not just in information technology; this visual representation helps in understanding and taking action in any day-to-day activity that we would like to optimize the overall experience/flow of.

It’s a great tool, not just to track and troubleshoot development projects, but also for maintenance and operation projects. You gain better insights using a cumulative flow design, and it helps in driving meaningful retrospection.

Advertisement

XP: An Obsession for Simplicity and Productivity with Focus on Humanity

Venky (Enterprise Architect): “Hey dude, Agile isn’t working for us and we are wasting so much time in ceremonies with no fruitful outcomes.”

Ramesh (Agile Practitioner): “Well, let us start with the objective. What are you trying to do?”

Venky: “For our upcoming release, we are trying to add a new technical capability which we haven’t done before. We like to research and explore the feasibility before full-fledged implementation.”

Ramesh: “Basically, you are building architecture runway and there are lot of unknowns…”

Venky: “Yes, we are following Scrum currently and it’s quite challenging to plan and execute leveraging Scrum.”

Ramesh: “Because…?”

Venky: “We are dealing with unknowns and we don’t even know how many uncertainties there are. As I said before, this is new, and we are prototyping and it’s not easy to plan and size the effort even at a high level”

Ramesh: “So Scrum is not working for you. Also, your requirement is evolving and rapidly changing as you progress and discover the unknowns.”

Venky: “That’s right”

Ramesh: “Agility is all about uncovering better ways of developing software through four core values. So, it’s not that Agile is not working for you. We need to find the right Agile methodology that fulfills our needs.”

Venky: “Spot on, let’s do it.”

This conversation led us to explore various methodologies before we decided on eXtreme Programming (XP).

We started with the knowledge matrix to understand where we are currently so that we can choose what works best for us.

Illustrating the above with some examples:

Known Knowns

Let us take an example of chatbot implementation in an iteration. There may be several technical challenges and complexities during the execution. But all requirements can be clarified, and the team has enough artifacts available in platforms like StackOverflow to proceed.

Scrum may suit this better since the Product Owner can explain the needs, and the Scrum Master can help with the removal of blockers and enables the team while the team self-manages the work.

The team can leverage daily stand-ups and demos to understand the progress and take the early feedback.

Known Unknowns

An example would be a dependency on other Scrum teams and other business units. We are aware of the dependencies and when they need to be resolved by, but we are not sure about how the work is progressing in the unit we’re dependent on.

Frameworks like Scaled Agile may work well where the cadence and alignment are the primary objectives. Synchronization through program increment planning, Scrum of Scrum, and demos enables transparency of unknowns.

Unknown Knowns

Operations and support functions fall into this bucket where we need to react as quickly as possible based on customer issues. We know the nature of work and steps, but we don’t know the frequency of inflow and complexity involved.

Kanban is ideal here since the methodology helps in scheduling the work just in time. Over time, Kanban helps in converting unknowns into measurables through lead time and cycle time.

Unknown Unknowns

Our requirement of research fits into this category where the resulting work may not be just the software product also domain knowledge and building blocks for architecture runway.

The challenge here is the rapid change of requirements and need for some development along with exploration to discover the unforeseen implementation problems. The spikes may not be very effective here. Extreme programming comes to our rescue in addressing these challenges.

Extreme programming is straightforward with just two roles

• Customer (in our scenario it’s Venky): responsible for making all decisions regarding the architecture runway 
• Developer: responsible for realizing requirements identified by the Customer.

There are two additional optional roles, the tracker, to keep track of progress and identify areas for improvement, and the coach, to mentor the team in XP practices.

We have taken advantage of the XP approach by setting goals on a daily (and hourly for some cases) basis with the objective of teams being able to ramp up quickly and identify implementation approaches. The plan is to assess at the end of the time box and change the course of direction accordingly. The team felt the methodology is simple and developer-friendly since the core values of XP: Communication, Simplicity, Feedback, Courage and Respect, are preferred by everyone.

The pair programming concept was leveraged where the developers participated enthusiastically not just within one group, but across the entire team. Even before the target, the team geared up and built confidence on the implementation approach. The informal methods encouraged by XP are liked by everyone since innovation and respecting each other’s’ ideas are core DNA of any development team. The team was able to size the work better with increased confidence.

XP practices as summarized below are simple yet powerful. The inherent advantages we felt are not just the productivity and increased collaboration, but also the simplicity yielded and a built-in quality that everyone strives for.

In summary, it’s not about a comparison of different methodologies; you must choose the right one that works for the team effectively. While every Agile methodology has its own merits, the knowledge matrix helps in identifying the suitable one. XP’s core strengths are fine scale feedback at every milestone, continuous processes that enable the customer, shared understanding within the team and customer, and maintaining the programmer’s welfare through a sustainable pace.

Let’s Lean on Lean (What’s in the Metrics: Part 2)

Look at your Lean process, then look at this article to determine if you are paying enough attention to how much waste your pipeline has.

“Hey Ramesh, we understand cumulative flow now and we also know which flow has longer cycle time. What should we do next to optimize the flow?” This a question I’ve received from folks who read the article on cumulative flow diagram.

Let’s revisit our flow diagram:

It’s evident that the cycle time is higher for work items in the flow “In Progress->Done” compared to the “Done->Shipped” flow. Let us see how we can optimize the flow.

Value stream mapping is a powerful method for identifying the waste in the entire process flow and helps to achieve the desired state. It is one of key Lean concept in manufacturing systems, but is also applicable almost in every domain. Though it has several symbols, flows, and guidelines to follow, the approach is quite simple with identification of value added, and non-value added steps in the entire flow.

Let me explain this with some examples from the development flow (“In Progress-Done” as above):

• Building code with built-in quality: Value-added step.
• Code review: This may be a bit confusing as this sounds important. But if we ensure the built-in quality during coding, we may not require this additional step. However, we also need to see the cost of quality if the defect is detected late in the cycle. Hence, this may be an example of a non-value added but necessary step.
• Build time: Waiting for the latest build is a classic example of a non-value added step and falls into the standard type of “Delay/wait time” waste.

Lead time is what the customer feels, and value-add is what they are willing to pay for. For an ideal Lean flow, the value-add should be the highest with optimal value enablers and minimal to none non-value add.

While value stream mapping seems to be simple and straight-forward, listing below five critical points to be considered for effective outcomes:

• Classification is critical: For each process step, it’s important to classify (value add, non-value add but necessary, non-value add) from customer perspective than how we perceive it to be. It is possible that value-add for one process may be non-value add for another process. Also, it need not be always the cost customer willing to pay, it’s equally important to understand the cost we need to avoid (in the above example, the code review will limit the cost of quality) to arrive at the proper classification.
• Every process step counts:
  • What’s the big deal about ignoring non-value added steps that take only few seconds? Well, think of this process step not being followed 100 times, 1000 times and so on.
  • What about the process steps we don’t own? Most of the time these steps are put in a black box and we tend to leave this as is. It is immaterial if these are internal or external, we need to work with everyone involved to identify the waste at every stage. System thinking is critical in striving towards perfection. As John Shook states, “Lean isn’t lean if it doesn’t involve everyone”.
• The process must tell the real story: The value stream should depict what’s happening in the proces, not what we think it could be. It’s important to understand the domain or have someone with domain expertise help us putting value stream together.
• Scenarios: Lead time of any process may vary time to time, which leads to the question of what to represent for value-added and& non-value added steps, best case, worst case, or regular scenario? It depends on the frequency of each scenario. Value stream mapping gives the visualization of as-is process and what represents the current process should be captured – it could be average, minimum, maximum or any other statistical measures.
• Automation is the cure for everything: Manual effort reduction through automation is great. But if we are automating the process without Leaning it, we are just converting manual waste to digital waste. Let us not forget about the resources required to perform operations even if the process steps are automated.

Value stream mapping is extremely resourceful in identifying and eliminating the waste in the flow when it is leveraged in the right spirit. Over a period, the value-added steps might turn into something customer don’t want. It’s important to revisit the value stream mapping and optimize it frequently. After all, Lean is not a one-time activity.

Scaling Business Agility: Three Essential Pillars for Being vs. Doing Agile

The difference between being a large Agile organization and simply calling yourself one is by correctly scaling Agile with these three tenets.

The concepts of Agile, Scaling Agile, and Business Agility have become buzzwords. The crux of being Agile for the customer and people who are building products and services is buried under a focus on conducting ceremonies.

Prior to scaling Agile, let us not forget the manifesto for Agile software development. It’s all about uncovering better ways of developing software that provides value both to the customer and for people who are part of the delivery stream.

Business agility can be associated with the value ecosystem as below:

Scaling adds complexity to the whole value delivery cycle. It’s a myth that only when we have larger teams involved do we need to scale up. Listed below are a few parameters that add challenges and require scalability at individual and system level:

• Communication and collaboration across distributed teams
• Architecture balance between legacy and modernization
• Continuous integration and continuous deployment across multiple business units
• Dependencies
• Roles and responsibilities within and across teams
• And many more…

An Agile mindset doesn’t happen overnight; let’s explore the pillars for being Agile as we scale.

People

Organization Culture 

If each business unit within an organization operates as a separate function, this has to be the first candidate for transformation. Even before we align the cadence and processes, it’s important to ensure everyone understands the purpose of working together. System thinking evolves as we help the team understand the vision and purpose.

Top management must be aligned before a team gets involved.

Transparency and working agreements within and across teams are vital in building a healthy culture.

Leadership

It’s at all levels, not just top or middle management. This is about enabling and adding value at every level in the ecosystem. It starts with product management who plays a crucial role in identifying and communicating value to the entire stream. From Engineering and Support to Program Management and Sales, everyone has a role to play in the value ecosystem. Those leaders must be identified and nurtured by management and the leaders need to hone their skills, not just to show or lead, but to be part of the journey.

Balance Between Customer and People

While we focus a lot on the customer and delivering the value for them, let us not forget the folks who are bringing those value. The Agile Manifesto talks about working software, while at the same time developing it at a sustainable pace by motivated individuals. The motivation becomes quite a challenge especially when the people are part of different value systems and are coming together for a common purpose. For knowledge workers, the work itself is the key motivation. Hence providing a clear vision on business, product and architecture along with the role they play are essential. HWell, happy employees try to make customers happy.

Technology

DevSecOps 

Who says Agile is all about just processes and practices? As we focus on delivering value in minimal predictable cycle time, it’s important to make our continuous delivery, continuous integration, and continuous deployment pipeline stronger. The toolchain for coding, building, testing, packaging, configuring, releasing, and monitoring must be carefully aligned with the organization culture as well as the value ecosystem. The DevOps team should be an integral part of the development team instead of behaving like governing function. As we scale up, it is essential to incorporate security in the whole value stream. Hence DevOps needs to scale up to DevSecOps. Every individual irrespective of their role must understand the critical role DevSecOps play and should upgrade themselves to be comfortable with the toolchain and value it brings in.

Practices

Framework

There are several frameworks available such as SAFe and LeSS to help the enterprises scaling up Agile. The framework should fit our purpose, not the other way around. It’s important to evaluate the framework for a fit in our organizational culture, technology, and adaptability to customization. Frameworks are intended to be used as-is, but we need to see if they are adding value or hindrance. Let us not forget our foundation of the Agile Manifesto and value ecosystem while we adopt and transform for the framework. After choosing the framework, for underlying Agile methodologies, we can leverage the knowledge matrix explained in the article “XP: An Obsession for Simplicity and Productivity with Focus on Humanity” as one size doesn’t fit everyone.

Lean Flow Focus

As we scale up, we might be introducing new processes and practices. At each step, we need to question ourselves on how this is adding value overall. We need to increase value-add, minimize the value enablers and eliminate the non-value add. For further reading on how we can optimize the value flow, please check out the article on “Let’s Lean on Lean.”

In summary, we can scale up business agility focusing on business outcomes by motivated individuals through leadership. At each level in the value stream, everyone has a key role to play:

• Product Management: Vision, roadmap and defining the value
• Architect: Laying the path ahead
• Program Manager/Scrum Master: Alignment & removing the roadblocks
• Team Member: Delivering the value
• Leadership: Leaning the non-value elements
• Cross functional teams (Support, Sales, Marketing, etc.,): Value enablement

Enablement Over Facilitation: 5 Essentials to Be a Great Scrum Master

Being a Scrum Master isn’t just about knowing the jargon associated with the role. It’s about being able to build trust, see the big picture, and enable success.

“We don’t often get the respect we deserve”, “Folks think our role is not a critical part of delivery”, “It’s a thankless job” – we hear this quite often from our Scrum Masters. While the road to becoming a Scrum Master is short, becoming inclusive isn’t as smooth as one thinks. Gaining respect as a Scrum Master requires a lot of dedication, persistence, and introspection. A valuable Scrum Master always goes beyond doing the “cliched” administrative work and adds value by enabling the team.

Based on our experience, we have listed down 5 essential skills that can help gain inclusiveness and respect as a Scrum Master.

1. Build Trust

The critical measure of a good servant leader is trust. Without trust from the team, no matter how hard one tries, it’s hard to succeed in any role.

When people trust us, they are ready to follow our lead and walk along with us.

In his book Speed of Trust, Stephan Covey talks about the framework to gain trustworthiness quotient.

Trust has two dimensions – Character and Competence.

• Character is a constant – It’s necessary for trust under any circumstances. 
• Competence is situational – It depends on what the circumstances require.

Building trust with the team is a stepping stone to earning their respect. People value us when we don’t just talk the talk but walk the walk with a great attitude along with delivering the right results in the right way.

2. Psychological Safety

Google’s massive study on team performance reveals that the highest-performing teams have one thing in common: psychological safety.

 “Psychological safety is a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.” – Stephen Covey

One of the core values of agility is openness. If people are afraid to speak up, then even if we achieve the business outcomes, the productivity won’t be sustained long enough. As part of forming a team, it’s essential to understand team dynamics as well as awareness about individuals. The personality studies such as Myers Briggs (MBTI) and DISC assessment come handy for Scrum Masters. Working agreements, mutual consensus, asking questions, and inviting people to open up and talk about their perspectives will also help in achieving mutually desirable outcomes.

Conflicts must be healthy and not lead to blame games, judgment, and disrespect. Hence the role of the Scrum Master becomes crucial in conflict resolution leading to personal safety while achieving business objectives.

3. Domain and Technical Expertise

The level of technical expertise required for Scrum Master is always a debatable topic. An extremely technical Scrum Master may end up dictating the team on ‘how-to’ rather than creating an environment to come up with great ideas. A person with no technical background may be clueless about the impediments and mitigation plan to address them. Hence the Scrum Master won’t be able to help the team in a timely manner.

What is important is striking a balance. While extensive technical knowledge is not a mandate for a Scrum Master, a familiarity with the project-specific domains will be a boon for the Scrum Master as well as for the team. This helps to build trust through competency as we discussed earlier.

4. The Scrum Master Role Goes Beyond Facilitation

Facilitating ceremonies suggested by various Agile methodologies is NOT the only job of a Scrum Master, rather facilitation is just a part of the job.

Agility is all about delivering value to the customer in the shortest possible time and the Scrum Master’s role is to provide enablement. We should be flexible enough to understand team dynamics, the nature of change, and other parameters that influence the delivery cycle and adjust the processes and practices as required.  

While theoretical knowledge is good, it’s important to reap the benefits by leveraging the underlying concepts. For each and every step in the value stream, a Scrum Master should ask whether that step is necessary in order to eliminate the non-value added elements in the overall cycle.

One of the challenges for Scrum Masters is to choose the suitable Agile methodology for the team. The article where we discuss out of box thinking and choosing based on the knowledge matrix might help.

5. Be Aware of the Big Picture

Sometimes being too focused on the team level commitments may help in doing an excellent job for that iteration and team. But we should remember we are operating at a system level and a holistic view is critical for success.

“People are working harder than ever, but because they lack clarity and vision, they aren’t getting very far. They, in essence, are pushing a rope with all of their might.”  – Stephen Covey

It’s important for Scrum Masters not just to know about the big picture but also to help the team understand and be part of it.

The team needs to understand ‘WHY we are doing WHAT we are doing and HOW this is going to help the business WHEN we deliver this’ and the Scrum Master plays a crucial role in enabling the team with the required knowledge.

Conclusion

The Scrum Master role is not an easy job. It requires knowledge on where to put our energy, retrospect on what’s working and what’s not and then working on continuous improvements. We need to ask ourselves if we want to help enable our team and experience the satisfaction of being part of the journey or if we want to think of it as a thankless job. The choice is always ours!

Co-authored by Anusha Kalvala

In the Spirit of Business Agility Transformation

An Agile transformation begins with the proper spirit and understand, and although Agile focuses on teams, that starts from the top.

“We want to be Agile to fulfil the rapidly changing requirements from customers through self-empowered and motivated employees” as opposed to, “We want our team to do Agile since everyone is doing it” is the true spirit of business agility transformation.

The journey begins with leadership

 While agility sounds like a bottom-up philosophy where individuals in the team are self-disciplined and self-empowered in achieving the common objectives, the journey starts with leadership through trust and leading by example. Leadership needs to understand the dynamics of the team and provide guidance since one size doesn’t fit all. Being transparent about the mission and vision is important to gain the shared commitment.

Optimization at all level

It’s a myth that agility is just for product development and support organization. Every individual in the ecosystem plays a vital role in transformation as we can’t expedite the delivery by optimizing silos. Visualizing and eliminating the waste in the value stream that translates an idea to implementation inclusive of process and people are essence for transformation.

Measurement

Both qualitative and quantitative measurements are important to understanding the health of business agility. While the organization can choose metrics that work for them, it is vital to measure throughput and cycle time of business outcomes.

Kaizen(Continuous improvement) and Kaikaku (Radical change)

Measure, refine and repeat — continuous and relentless improvements are important aspects to get better on our journey. The entire value stream requires retrospection in a reasonable timeframe to be able to adjust and move forward.

During the journey of transformation, there are a couple of myths to be considered:

Agile is not ad-hoc

In fact, there is a lot of planning and course correction when we adopt Agile but they are incremental and of short intervals. Since wait time is one of the key wastes, everything requires planning but not in detail just to ensure “roughly right.”

One size doesn’t fit all

In the name of Agile, we shouldn’t force fit the methodologies to a team. While Agile is all about incremental and iterative development, every methodology has its own merits and demerits based on the nature of work. For example, Kanban may work better than Scrum in an environment where scope of work changes daily.

Agile requires more discipline than we think

If a team feels there are too many meetings and ceremonies, it’s time to check the fundamentals. Every ceremony requires the purpose, pre-requisites and expected outcome clearly articulated to the participants. Time-boxing plays a critical role in Agile. Agile empowers everyone with a collaborative approach and taking consensus through working agreements, at the same time it expects every team member to adhere to what they committed to. Being proactive in raising the impediments, limiting the unfinished work through teamwork and self-organized are some foundation blocks for agility.

Beyond traditional leadership

The role of leadership becomes more of an enabler in unblocking impediments as well as bringing alignment within and across teams. The leader becomes frontrunner in transformation journey and guides team through continuous learning and mentorship. The leaders in Agile transformation don’t just show the way, they also travel along with the team, remove the hurdles, and enable teams to be successful.

Summary

To summarise, before the team embarks on an Agile transformation the leaders need to ensure the vision is communicated effectively for better collaboration and continuous support is provided through relentless improvement. We can be Agile without even following the ceremonies; what matters is how we convert the concept to cash for the customers in minimal predictable cycle time. 

Author:

Ramesh Manickavel, Director, Agile Program Management, CA Technologies