Agile Manifesto Revisited

In the current wake of COVID 19 while we all are confined to our homes, it is is not a punishment rather if we look at it with a positive aspect, we now have more time to dedicate to our families our hobbies and our growth. This pandemic has shown us the path to some great opportunities ahead.

Likewise, the agile manifesto that was drafted way back in 2001 did consider all this. It said that – While the items on the right are important, we value the items on the left.

Now, it should be…”While the items on the right are important, the valued items on the left will not reach it’s effectiveness without the items on the right“.

Individuals and interactions over processes and tools

• 

We have to rely on processes and tools to have more interactions with our teams

Many employees across the world found themselves using videoconferencing for work for the first time. They assumed it would be like using FaceTime but encountered several issues, including a lack of device interoperability, poor desktop-sharing experiences, and difficulties adjusting audio devices. But, some tools can help us function just like the way we operated from office. The difference being now we are more connected to our families while our peers are on screen. 

Working software over comprehensive documentation

• 

Overwhelmed customer service teams on the vendor side couldn’t respond to the questions of so many new users. Multiple vendors claimed that their inquiry volumes increased by an order of magnitude during that period. They don’t want to rely on documentation alone. They want to see it, experience it. And, that’s where we will need more effective tools to do so.

Customer collaboration over contract negotiation

• 

We do need a contract in place before we start executing the project and the customer collaboration relies extensively on the collaboration tools like Skype, GoToMeeting, Slack, Zoom, etc. 

Research shows that active users, who rely heavily on sending documents for collaboration, are concerned about the risks inherent to sharing documents online. Although SaaS providers have demonstrated the security of their cloud storage offerings with encrypted networks and permission control systems, customers are still unsure of how safe their documents and personal information are when using tools. And, that’s what is the need of the hour.

Responding to change over following a plan

• 

Times have changed and so has the focus. The world wasn’t prepared for the pandemic and hence had to enforce new laws and introduce changes in the way we used to function earlier. Responding to change was mostly limited to the changes in the client requirements, we never thought that we will have to change the way we operate, commute, and communicate. 

Once all this is over and as enterprises resume normal business activity, they will notice that an effective collaboration strategy needs to align the business and technology objectives and coordinate work streams across cross-functional teams. Current pilots are only part of the holistic adoption assessments needed. 

To succeed, tech and business leaders will have to advocate for management support, cultural change, and adoption strategies for Employee Collaboration instead of simply defining a SaaS roadmap.

• 

Advertisement

Business Realities

Businesses want to reduce cost and risk while increasing revenue. To succeed as a software developer, don’t try to sell working software for less money than others; instead, reduce cost, reduce risk or increase revenue for those companies. I will discuss a few ways to do these things, and do them well.

1) Provide Guarantees.
So the other person provides a lower hourly cost. So what? Does that mean that the total cost is going to be less? Most people that deal with software contractors know that an estimate is rarely worth the paper it’s printed on. That’s why fixed-price and fixed-date contracts are so appealing to customers: It moves the risk from the shoulders of the customer to the selling organization. As long as the buying organization is certain to make money, hourly rates won’t matter. (How do you compare $6/hour and “We think it’ll take about six months” to “$10,000 and it will be done in three months.” How about to “I’ll take 30% of gross revenues. If you don’t make a dime, I don’t make a dime…and this will encourage me to make it good enough to re-sell”)

2) Analyze the business and provide a better solution

“Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want.”

Joel Spolsky

In other words, the attitude of “Just give me the requirements” fails because it has the customer solving the problem; the software developer becomes just a glorified technical writer that knows how to write in the language of a machine.

3) Dramatically decrease the defect rate
Are people willing to pay for quality in software? Sadly, generally, the answer is no. Quality in software is hard to measure; unlike automobiles, there is usually no crash or endurance tests to compare against, especially for custom software. Yet we all know that plumbers, electricians, and roofers with a reputation for quality have more work orders than they know what to do with. Producing software with less defects, that is usable, that does what the customer expects will net a major competitive advantage for years to come.

4) Create well-documented, maintainable code
Despite all the jokes about job security, companies want well-documented, easy-to-understand and easy-to-change systems. This allows them to reduce risk, and, as we’ve previously discussed, reducing risk has tangible, measurable value to a company. The great thing about increasing the value of what you sell is that you can now charge more for it.

5) Provide better feedback
If you prioritise every feature, you can work on the most important features first. A series of small releases gives the customer the most important features first and the opportunity to provide feedback. This is not a new idea; it is one of the core ideals of the Extreme Programming model, and it’s an excellent way to give the customer more while costing you less. (Think about this: Most large projects run late and over budget. Many small projects do not. Instead of “biting off more than we can chew” next time, why not refuse to run a large project and instead run a series of small projects?)

6) Show the customer how you will make them money or allow them to cut costs.
This one is a no-brainer. It’s easy to charge more for your services and still win the bid if you are selling something fundamentally different: This is why McDonald’s franchises sell for more than Jerry’s Pizza Shack franchises. Imagine the two sales pitches:

Jerry’s: “Hey, for $10,000 and 3% of your sales revenue, I’ll let you use my name, my sign, my recipes, my suppliers for food, cups, plates – the works!”

McDonald’s: “For $1,000,000 and 8% of your sales revenue, we’ll give you everything Jerry does – plus throw in a lease on a furnished building in residential area X. We’ll promise no McDonald’s competition (except the ones you own) in a 50-mile radius of your store. We’ll provide management training for your people. In fact, here’s a breakdown of our 200 stores in areas with a similar population to X, and their sales compared to expenses for the first five years of business. As you can see, since 1995, only 10 of those stores failed to be profitable within three years, and they were all profitable within five years.”

Conclusions
From the last example, you can see that McDonald’s and Jerry’s are selling two fundamentally different things. They both seem to “solve” the same problem: “I want to own a fast-food business.” McDonald’s chooses not to compete on price; instead, they compete on delivered results.

Most banks compete on delivered results for investment. While they may occasionally advertise that they have low or no minimum balance, it is far more common to hear about a low rate for a loan or a high rate for an investment. If we are to survive the coming bust, we must Promise and Deliver Results. These results must substantially differentiate us from other, cheaper competition.

If you try to build a house and base every decision on cost, you will probably get what you deserve. Most people know this, and factor other things into the decision. As the software industry matures, we must learn to provide and market those “other things.” In order to survive, we must stop being glorified technical writers or creative story tellers and become businessmen…and the need for good businessmen is not decreasing, but instead it is constantly increasing.

Retrospective using the 4L theme combined with Tuckman’s Model

In the previous article we learned how to use the 4L technique for a retrospective and how effective it proved to encourage the team to talk and discuss points that in a normal day wouldn’t be possible. It is one of the effective ways to resolve conflicts in a group.

In this article we will learn more on how we included Tuckman’s model in the 4L Retrospective technique.

• 

Purpose

Being true to the Spotify model wherein the focus is on autonomy we saw value in merging 4L (Liked, Loved, Lacked, Longed) + Tuckman (Forming, Storming, Norming, Performing). This helped in identifying where we need to focus on keeping in mind the organizational goal towards Growth. We will call it Tavision. Tuckman’s model helped us to identify the correct state we were in and identify ways to improve on those and move to the next level.

• 

There are other models too that could give similar results like the Cynafin framework which is more aided towards decision making. However, we choose the Tuckman model because you also need to know the maturity of your teams in adapting to new ideas and ways of doing things. Cynafin at this point was for an advanced stage of doing our retrospectives.

The Agenda (10 Minutes)

Before starting with the retrospective, the IM took 10 minutes to explain the agenda.

• 

For that IM used the Five levels of conflict:

1. Intra-Person– Personal challenges – this has to be solved at a personal level, not with the squad.
2. Inter-Person – Conflicts between two or more individuals in the squad. This has to be sorted between the individuals or with their manager.
3. Intra-Squad – Challenges within squad w.r.t to the sprint work and achieving the sprint goal.
4. Inter-Squad – Challenges with other squads in achieving the sprint goal.
5. Intra-Organization – Challenges at the organization level that needs to be addressed by the leadership.

The agenda was set – the squad was to discuss only on the conflict level 3 and 4.

The Execution

(Total 1 hour, can extend to 2 hours depending on the size of your team and experience with retrospectives)

Explain the Tuckman Model (5 minutes)

Once the agenda was set all squad members were explained the Tuckman model.

Tuckman’s model is significant because it recognizes the fact that groups do not start off fully-formed and functioning. He suggests that these phases are all necessary and inevitable in order for the team to grow, face up to challenges, tackle problems, find solutions, plan work, and deliver results.

• 

1. Forming – Made aware of things. Learning.
2. Storming – Chaos. Need maximum focus.
3. Norming – Started working on the solution but still need more focus.
4. Performing – Doing it as expected.

The List

Once the squad understood what was expected from the retrospective. They were asked to come up with points that they thought was in the Inter-Squad and Intra-Squad level of conflict. This was a group activity wherein IM wrote all points from the team on the white board.(15 minutes)

• 

Next Steps

• Each member was asked to place the items on the board into the four quadrants.

• 

Note: There will be instances that many items on the list will be repeated in different quadrants. And, that’s what will initiate the discussion.

• Once all the items from the list were added to the quadrants we formed four groups and asked each group to pick up all items from one quadrant and further distribute those into the four quadrants as per the groups understanding.

• 

• 

• 

• 

Note: Do this for two rounds or till the group comes up with the top items for each quadrant. Let the squads decide the top items that they want in each quadrant. Further, if needed you can initiate the dot voting to identify the top 3,4 or 5 action items in each quadrant.

In this case the items in the Storming phase will be the top most action item.

• Once the squads identify the top action items everybody in the squad would know the correct state of their squad. And, then identify ways to improve on those items.
• As mentioned earlier the execution was based on the 4Ls Technique, you will need: Post-it notes, flip chart paper, white board, pens etc.

THEN IT WAS TIME FOR APPRECIATION WITHIN THE SQUAD AND CELEBRATE THE PAST SPRINT, WITH PIZZA… 🙂

• 

The “Happiness Metric”​ Part 1

The “Happiness Metric”, it’s one of the most popular metrics in the Agile community today. Some organizations consider team, and sometimes organizational, “happiness” as a necessary ingredient for high productivity and value creation. But is this really true? Is “Team Happiness” a prerequisite for high productivity and value creation ……. or is it just a consequence of high productivity and value creation?”

In this article I would like to examine the first part of my question: “Is ‘Team Happiness’ a prerequisite to high productivity and value creation?”. (I will cover the second part of my question: “Is ‘Team Happiness’ a consequence ofhigh productivity and value creation?” in part 2 of this article).

To explore if “Team Happiness” is a prerequisite to high productivity and value creation I’d like to start by telling a story. A story about one of the most successful teams in U.S. history.

 I call this story “The Dynasty”.

The Dynasty

Once there was a team, an extremely successful team. A team that, year in and year out, was recognized as the best at their craft. Coincidently this team was also a rather diverse team for its time, containing members from different backgrounds, cultures and ethnicities. This team became so successful that it became recognized as one of the best teams in the history of its industry. They had a unique team dynamic and the members had unique interpersonal relationships.

During their most successful years this team was widely known to be contentious at best, combative and downright dysfunctional at worse. They fought among themselves constantly. They’d insult each other, criticize each other in front of other team members, threaten each other, and be on non-speaking terms for long periods of time. One team member would later say “Those guys had some truly vicious tongues, when they’d start talking about each other, it was something to behold.“

Sometimes the verbal attacks and threats would escalate into physical altercations. Some physical altercations escalated into brawls. Team members suffered sprained ankles, injured shoulders, head gashes and even a herniated disc requiring the team member to be put into traction. As another member of the team would later say: “We had some characters and we were beating the (expletive) out of each other. But we still won.”

You’d think that these “incidents” would be enough of a challenge to overcome but there was more. The team’s boss was a notorious micro manager and the cheapest man in the industry. He paid the team the lowest salaries in the industry even though they were recognized as the best. The boss would publicly say they weren’t worth pay increases. The team universally hated him. One team member publicly called his boss “A cheap son of a bitch”.

And in the public is where it all played out, with millions of people reading about it and hearing about it.

But despite all this they became the most successful team of their time and is considered one of the best in history.

So, you may be asking:“Well, who was this team” and “what industry did they work in?”

Well, the team was the 1972, 1973, and 1974 Major League Baseball World Series Champion Oakland A’s and they are one of only two teams in the 116 year history of Major League Baseball to win 3 World Series Championships in a row, qualifying them as a Dynasty (the New York Yankees was the only other team to do it and they did it three separate times).

Now, you may ask:“How in the hell, amongst all that turmoil and hostility, did this team become­­ so successful?”

Well it’s safe to say it wasn’t “Team Happiness”.

We can also leave out “Management Support” while we’re at it.

The things that allowed them to overcome all the turmoil and hostility and achieve greatness was:

Purpose

The team had a purpose, to prove they were the best at their craft. They wanted to prove it against their competition, to their cheap @#* boss and especially to themselves.

Cross-functionality of Skill Sets

The team was highly skilled in all the areas needed to be successful

Long lived Autonomous team

Most of the team members played together for years in minor league baseball before being promoted and playing together in the major leagues.

As quoted by the most famous member of the team, Hall of Famer Reggie Jackson: “We had played so long together as a unit that we knew where everybody would be without looking…. It was all instinct with us.”

Baseball?

OK, I know what you might be saying: “Baseball! baseball! Are you kidding me man? Agile teams create advanced technologies that help improve people’s lives and you’re talking about freakin baseball! Give me a break!”

OK, maybe using a sports team example could be considered a bit of a stretch. Perhaps there’s a technology company that was very productive and successful, maybe even legendary, where happiness of the staff was not a contributing factor to the company’s success. Hmmm, let me think, there must be at least one. Think now… think …think, oh yeah, that’s right: Apple and Steve Jobs. Intimidation, abrasive criticism, downright cruelty, these were the calling cards of Steve Jobs. He created a culture of fear at Apple, yet no one can deny the legendary success he created there.

Is “Team Happiness” a prerequisite tohigh productivity and value creation?

Based on the two examples I provided in this article it can be safely concluded that “Team Happiness” is not a prerequisite to high productivity and value creation.

So now you might be wondering: “OK, so ‘Team Happiness’ is not a prerequisite to high productivity or value creation. Are you trying to say happiness plays no role in Agile at all? I don’t believe that!

And that’s where the second part of my question comes in: “Is ‘Team Happiness’ a consequence of high productivity and value creation?” I’ll answer that question in part 2 of my article. See you then!

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.

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.

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