agile

The Essence of Agile

A question, “What exactly is Agile?”, keeps troubling people.

They either make reference to the manifesto or map it with Scrum and then get circled in its events and practices.

Though Agile movement started as a better way of developing software, it has moved beyond software development.

Agility has evolved into a way of thinking, permeated to organizational work culture, experimentations, better ways of doing business, product development and servicing customers.

It started in the context of and in reaction to the Waterfall approach initially. Now it doesn’t have anything specific to compare to. It’s ever-evolving.

That’s the reason, even though the movement began with Agile manifesto, the manifesto in itself didn’t remain a constraint in making further improvements ever. In the last few years, people have evolved and embraced Modern Agile concepts, Lean thinking, Lean Startup and Design Thinking approaches for the same reason.

Definition

If you look at the online dictionary, ‘agile’ means “able to move quickly and easily” with an emphasis on changing direction. Taking a cue from its dictionary meaning – ‘agile’ is the ability to create and respond to change, quickly and with ease in order to succeed in an uncertain and turbulent environment.

From the software development perspective, in the late 1990’s, several software development frameworks emphasized close collaboration between the development team and business stakeholders; frequent delivery of business value, self-organizing teams; and smart ways to craft, confirm, and deliver code.

In early 2001, 17 software development practitioners gathered in Utah to discuss their shared ideas and various approaches to software development.

‘Agile’ is an ordinary word in English, it means “able to move quickly and easily” (online dictionary), with an emphasis on changing direction. It was for that reason we chose the word to match the sense of the way we wanted to work, when discussing our approach to software development back in 2001.
— Alistair Cockburn

Once these practitioners had the word in place, they had to decide what it meant to them for the purpose of writing software. They chose 4 values to centre themselves in the world while working and added 12 principles.

Question: There may be innumerable practices suited to, or may evolve in a context. How to ensure if those are acceptable in Agile methods?

Answer: Agile methods are based on common sense. As long as a method or practice is in line with the intent of agility and with Agile values and principles, you are fine.

For instance, a team realized that distributed retrospective along with the customer team was not helping them in solving local problems. They decided to have a local retrospective as well and it worked pretty well for them. Similarly, though the definition of Ready is not essential in the Scrum guide, it is tremendously useful in the context of distributed teams working in opposite time zones.

Summary

Essentially, agile is about:

Are we able to create change and respond to changes, quickly and with ease in an uncertain and turbulent environment?
Do we center ourselves on manifesto’s four values and principles?

References

Alistair Cockburn’s Interview

Passion Driven Work – Secret Sauce of Generating Exponential Value in a Company

by ShriKant Vashishtha Leave a Comment

This is a story of a small IT service company in India with a capacity of 80-100 people. The key USP of the company was its focus on flat hierarchy, extreme programming culture, getting great people onboard, technology innovation, thought-leadership and encourage people to become authority in their respective field.

Flat hierarchy for the simple reason — it could be one of the biggest blocker for empowerment, innovation and decision-making in a startup. So it was quite common to see a senior developer pair programming with a newbie.

By having flat roles you can build a self-organized and autonomous team, which then could take its own decisions.

Here are some of the snapshots of what we were looking for.

The Branch Merge Hell Team Lived With – A Bank Agile Case Study 1/n

by ShriKant Vashishtha 4 Comments

Lots of organizations are desperately trying to bring agility in their enterprise IT. In such cases, enterprise IT stands on the worn pillars of traditional Waterfall process and legacy products.

The business in such orgs sees IT as a black hole where no business need can escape from inside it. The reason being, traditional process, and legacy systems take months of cycle time to deliver almost any business need.

This results in a frustrated and desperate stakeholders who threaten to try anything or everything under the sun to get tangible outcomes.

This case-study is a story of a bank which was almost on the verge of outsourcing its entire IT. The bank since has moved on to become one of the pioneers in banking innovation space. It focuses to serve its customers every day with innovation and agility in a faster paced competitive ecosystem.
[Read more…] about The Branch Merge Hell Team Lived With – A Bank Agile Case Study 1/n

If You Need Kanban in Scrum, You’re Probably Doing it All Wrong!!!

by ShriKant Vashishtha 7 Comments

The original idea of Scrum came from a 1986 HBR article “The New New Product Development Game“, written by Hirotaka Takeuchi and Ikujiro Nonaka. The teams at Honda and elsewhere reminded Takeuchi and Nonaka of the game of rugby and they called this style of project management “Scrum,” a short form of the term “scrummage” where the game is restarted when the ball has gone out of play.

So what’s so significant about rugby scrum?

In rugby scrum, the ball gets passed within the team as it moves as a unit up the field.

Scrum is all about everyone doing everything all the time. It’s an important point to remember as otherwise, Scrum becomes yet another framework with 5 events, 3 roles, and 3 artifacts.

The foundation of Scrum encourages one-piece continuous flow.

So in a Collaborative Daily Scrum, instead of answering 3 daily Scrum questions, a team looks at the Scrum board and plans on how to swarm or mob to finish the top PBI (Product Backlog Item) on the board.

It may happen, depending upon the tasks identified for a PBI, 3-4 people decide to swarm and finish it. And then the rest of the team picks the next PBI.

Daily Scrum is a sprint planning in small. You replan the sprint every day.

If a team is working like this, there should be couple of stories (depending upon size) in progress at any point in time.

So you see, if a team decides to swarm or mob, one doesn’t require to set explicit WIP limits anymore. The disciplinary act of stopping at numerical WIP limits is not required as that becomes part of the system.

The team focuses on finishing existing PBIs before picking anything new.

As we discuss the key idea of collaboration (swarming or mobbing) here, it’s important to understand that the idea of “swim-lane Scrum” (each team member individually taking ownership of a PBI through the stages of the process) doesn’t really work. It blocks the delivery pipeline as any PBI a tester may work on comes after a few days, a week or so.

At that point in time, a tester may get multiple stories to test at once and may become the bottleneck. That kind of scenario is not the ideal state of flow but is more like a Scrumfall in which work arrives in a batch after a period of time.

Kanban Mythbusters Series

There are other posts on Kanban Mythbusters series which you may find interesting

References

Agile : The Dilemma of IT Service Organizations

by ShriKant Vashishtha Leave a Comment

I spent a big amount of my IT journey in working with IT Service organizations which Product organizations call as vendors.

While product organizations can decide how exactly they would want to work, teams from service organizations are mere extension from a customer enterprise IT strategy standpoint. Whether to work in Agile or not, Agile or AgileBut, all that is driven by the customer. If customer continues to work in Waterfall, you may not use Agile in isolation.

For service organizations, money comes from the headcount and the billing rate. As long as that’s improving while keeping the status quo, sometimes management may not see any specific value add in focusing on things which are not burning. That includes innovation, adopting Agile, TDD or focus on long term quality.

In short, customer drives the show. If customer is quality conscious, vendor follows the suit. Otherwise maybe not.

Service organizations play the software development service provider role in the enterprise development value stream. They focus on optimizing what they essentially work upon from Agile and DevOps standpoint which translates to improvising technical practices, automation and some DevOps technical practices.

While doing so, the trouble is – they don’t get the awareness of the whole, the whole enterprise landscape. That perspective is important for enterprises implicitly but not necessarily out of question for service organizations. It’s not easy to get such awareness. That’s the reason it becomes easy to miss.

In some Indian Agile conferences, where audience are majorly from service organizations, sometimes, people find anything beyond their technical scope as less useful. There, it seems like, automation and DevOps technical practices are the panacea of software development world. These practices are easy to talk about, difficult to implement and are definitely not the low hanging fruit for any enterprise.

There may be many other low hanging fruits which bring a lot of value add and reduces the cycle time without spending a lot of time, money and resources.

I understand the dilemma, however without understanding the whole or the big elephant, it becomes difficult to provide the real value add to the customer.

Good people in such orgs who really want to work in Agile environment find themselves helpless unless that’s the part of customer IT strategy. Employees may then get frustrated because of lack of opportunities.

What if service organizations are ahead of the curve and help customers in looking ahead? That requires spending on innovation and research which not many orgs do as of now. But you see, the focus on innovation has become important for survival these days.