The flow of work: The product owner makes an ordered list [Product Backlog] of what needs to be done. The development team members then forecast how much they can do in one sprint and self-organize to get the work done, deciding among themselves who does what to produce the new product increment.

The development team is a group of people [developers + testers] working towards single goal which is to build the desired product, by delivering value frequently and with supreme quality. They achieve this being small in size in order to enable effective communication. Self-organize to do work and plan. Scrum’s development team is collocated[recommended] and cross-functional, so that there is maximum effectiveness and minimum external dependencies in reaching the goal.
They work collaboratively, share responsibility, and are accountable for the successful delivery of value identified/stated by the product owner. The development team does the actual work of delivering the product increment. They are completely responsible and accountable for the product quality.
They work collaboratively to design architecture, develop features incrementally and iteratively.

Scrum recognises no title for any of the members of the development team other than a “developer” regardless of the work being performed by the team member. There are no hierarchies when it comes to the development team & there should be no exceptions to this rule.

Scrum recognizes no sub-teams in the development team [namely: testing, business analysis etc etc]. There are no exceptions to this rule either.

The Development team size is small enough to remain nimble but large enough to complete significant work. The ideal size is 3–9 members. Why 3, you may wonder? Well, lesser than 3 members decrease interaction and can encounter skill constraints to build a complex product. And, more than 9 members requires too much coordination and thereby, empiricism can take a hit. It is recommended that all team members be tagged to the team and the project full time.

Anyone who’s not executing the product backlog isn’t a part of the development team.

Few traits of a self-organizing team:

[1] Team voluntarily takes initiative: No one, not even the Scrum Master tells them how to convert product backlog into increments and potentially releasable functionality

[2] Contribution as a Team: Individual team members may have specific skill sets but the accountability to deliver belongs to the team as a whole

[3] Work towards solutions rather than stress over problems

[4] Cooperate with each other

[5] Improve continuously: Self-organising teams take retrospectives feedback on their chin and work towards self and team’s improvement

[6] Are empowered by the organization to organize and manage their own work.

It is ‘nice’ to start as a self-organising team but if not, then it should be the goal eventually.

Most importantly - before stepping into a Scrum team, please leave your ego and title outside the door.

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

[3] Why Agile?

[4]The Agile mindset: Doing Agile vs Being Agile

[5]The Agile Mindset — Lessons from M.S. Dhoni

[6] Utilization vs Productivity in Agile — Lessons from cricket

[7] Lessons in Agile from Mumbai Dabbawalas

[8] Agile Methodology Frameworks

[9] SCRUM — the theory

[10] First role in Scrum: The Product Owner

What is a PRODUCT?

A product is an intent to solve someone’s problem. The best way to build a product is to start with a purpose of making this world a better place. For example: Any activities that one performs in a daily life may have pains and problems like traveling from home to work everyday. If you look it from a different perspective, these pains and problems are nothing but needs, want’s and requirements. Now, one can provide solutions to these problems by calling it a product, a project, a service, an app, a tool etc etc. Call it what you want, but the heart of the matter is that we’re trying to solve people’s problems.

Now, what do you mean when you say that you’re an Owner? Suppose you own a restaurant. One day a guest complains of having found hair in the soup and requests you to do something about it. Can you tell him that — Please direct these problems to the Kitchen staff? No, you can not. As an owner you’re responsible for each and every activity in your restaurant.

Every product has 4 dimensions —

[1] Users: User research

[2] Buyers: Market research

[3] Sponsors: Business model design

[4] Dev team: Product development

If we split this dimension one way, we get:

[1] Users & buyers: This is usually an external activity facilitated by Product Managers

[2] Sponsors and Development: This is usually an internal activity facilitated by Project Managers

If we split the 4 dimensions the other way, we get:

[1] User research & product development: This is tactical work generally facilitated by Business Analysts/Product analyst

[2] Market research & business model design: This is strategic and is generally facilitated by Marketing manager

A Product Owner is responsible for all of these activities.

You could also say, Product Owner = Product manager + Project Manager.

or

Product Owner = Marketing manager + Business Analyst.

Too much, right? Well if you call yourself an owner, then you’re responsible for everything. And we all know that with greater power comes greater responsibility. As a Product Owner you are responsible for maximising the value of the product. You may seek help from Dev team, discovery/ research team & anybody and everybody but YOU OWN EVERYTHING.

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

[3] Why Agile?

[4]The Agile mindset: Doing Agile vs Being Agile

[5]The Agile Mindset — Lessons from M.S. Dhoni

[6] Utilization vs Productivity in Agile — Lessons from cricket

[7] Lessons in Agile from Mumbai Dabbawalas

[8] Agile Methodology Frameworks

[9] SCRUM — the theory

Scrum (n): A framework withing which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Let me break it down for you:

Scrum is described as process framework rather than a complete process for building products. One important distinction is that scrum is intentionally incomplete. It does not specify all the steps required to build a product. Instead, it describes a framework within which a variety of processes and techniques can be deployed.

The Scrum team consists of members and their associated roles [Product Owner, Development Team & Scrum Master], events [Sprint planning, Daily Scrum, Sprint Review, Sprint Retrospective] and artifacts [Product Backlog, Sprint Backlog & Sprint increment]. Each of these components have few simple rules and there are simple rules describing the relationship and interaction between the components. Anything not described by those components and rules is not a part of the framework. The Scrum team decides what processes and techniques to use within the framework. If the team or the organization were to decide to remove or alter any of the components or their rules, they are no longer using Scrum. Scrum exists only in its entirety and each of the core components and their associated rules serves a specific purpose.

The 2nd part of the definition describes something called a complex adaptive problem. To understand that, lets look at a spectrum. One one end of the spectrum we will place problems that are simple, unpredictable, and adaptive, or always changing. Most professionals are familiar with how to address at the left end of the spectrum. Since these are predictable problems, we are able to create a detailed plan. The plan might have many steps and dependencies, but if the system is predictable, the plan will progress without any surprises, or the need to change things along the way. This approach is known as defined process control, which means that we define a specific process for every step along the way. This works well when things are predictable.

When things are more complex and unpredictable, the approach is not very effective. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice. An empirical approach is based on observations and evidence. Empiricism is the central idea behind the scientific method — that we can find out what is true through experiments with concrete, observable results. In order to make good observations, an empirical process has 3 pillars: Transparency, inspection and adaption. Scrum is based on empirical process control, and so significant aspects of Scrum are designed to provide Transparency, inspection and adaption. To create transparency, Scrum’s events and artifacts are visible to all of those responsible for their outcomes. The frequency of inspection has to be balanced so it doesn’t get in the way of the work, but still provides sufficient opportunities to course correct. If, during inspections, anything is determined to be outside of the goals of the effort, the process, plans or product are adapted. The adaptation is made as soon as possible to optimize for a better outcome.

To summarize, Scrum is a lightweight framework made up of a few roles, events, artifacts and their rules that is simple to understand. However, since it relies on empirical process control to address complex adaptive problems, it is difficult to master.

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

[3] Why Agile?

[4]The Agile mindset: Doing Agile vs Being Agile

[5]The Agile Mindset — Lessons from M.S. Dhoni

[6] Utilization vs Productivity in Agile — Lessons from cricket

[7] Lessons in Agile from Mumbai Dabbawalas

[8] Agile Methodology Frameworks

Agile is an umbrella term for various software development approaches. The most popular approaches are:

[1] Scrum: A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

[2] Kanban: Kanban is a Japanese term meaning ‘signal cards’.

[3] Extreme Programming [XP]: is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.

[4] Crystal: Crystal method is an agile software development approach that focuses primarily on people and their interactions when working on a project rather than on processes and tools.

[5] Dynamic Systems Development Method [DSDM]: The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

etcetera, etcetera..

Be Agile, do Scrum.

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

[3] Why Agile?

[4]The Agile mindset: Doing Agile vs Being Agile

[5]The Agile Mindset — Lessons from M.S. Dhoni

[6] Utilization vs Productivity in Agile — Lessons from cricket

[7] Lessons in Agile from Mumbai Dabbawalas

Preface: Mumbai dabbawalas [men who pick up/deliver your tiffin] are a group of men who pick-up home-cooked food from your home and deliver it to your office before lunch time. They also deliver the empty tiffin back to your home on the same evening.

They live by the mantra — Happiness comes from WHAT we do. Fulfillment comes from WHY we do it.

Do you think the Mumbai dabbawalas are Agile? — you bet they are.

Some facts:

[1] Their error rate is 1 in 16 million transactions and they achieve this astonishing figure without technology. They firmly believe and prove that one does not need technology to be efficient.

[2] The Mumbai dabbawala organization is Six Sigma certified with a rating of 99.999999 and their average education is 8th grade pass-out which accounts to about 50% literacy rate in them.

Agile value: People and interactions over process and tools

[3] They also provide value added services at times. For instance, if you forget your specks or other important things left at home the Mumbai dabbawalas will deliver that to you as well along with your tiffin. It’s not a part of their deal with you but they believe Customer is God and they don’t fret over a deal.

Agile value: Customer Collaboration over Contract Negotiation

Agile principle: The best architectures, requirements, and designs emerge from self-organizing teams.

Agile principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

[4] The Dabba’s are color coded. If color codes vanish due to the washing.. the dabbawala will write it himself. He will not say that its not his job because within the organization everyone is responsible and accountable.

Agile Value: Responding to change over following a Plan & Customer Collaboration over Contract Negotiation

Agile principle: The best architectures, requirements, and designs emerge from self-organizing teams.

Agile principle: Simplicity — is essential.

[5] The Mumbai dabbawala association has a zero attrition rate

[6] No strikes in last 120 years

[7] They have no legal department and claim that they do not need one. This is largely because of the work satisfaction that each member has.

[8] They believe, a good team is a great asset. Every single member is an asset.

Agile principle: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

[9] 1 dabbawaala carries around 40 tiffins daily in crowded Mumbai local trains which weigh ~60–65 kgs and a tiffin changes hands at-least 6 times before it reaches the appropriate person and there has been no error since last 120 years.

Agile principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Be agile, do agile and the Mumbai Dabbawalas prove that it doesn’t take much.

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

[3] Why Agile?

[4]The Agile mindset: Doing Agile vs Being Agile

[5]The Agile Mindset — Lessons from M.S. Dhoni.

Let me explain..

Hypothetical scenario:

It’s the Super over [https://en.wikipedia.org/wiki/Super_Over]

Now, would you send Virender Sehwag to bat or Ravichandran Ashwin?

Facts: Sehwag was a hard-hitting befitting opener for India while Ashwin, once an opening batsman for Tamil Nadu, is decent with a bat but is primarily an off-spin bowler.

Scenario 1:

If your answer is Ravichandran Ashwin — then you’re utilizing the resource you have. But will Ashwin be productive in a Super Over? Probably, no. Most definitely he will put bat to ball but you wouldn't want that off a super over now, would you?

Score -> Utilization 1–0 Productivity

Probable thought behind the decision: Ashwin will eventually learn/can be taught to bat like Sehwag in the Super Overs. Will he? Probably but do you wish to take that risk? No betting man would. Even if he does, would you wanna risk loosing matches until then? No. Period.

Scenario 2:

If your answer is Sehwag — the you are utilizing your resource productively.

Score -> Utilization 1–1 Productivity

Now how does this apply to Agile methodology in our workplace? While following Agile, you have to be fast and deliver even quicker. So while planning the Product vision and the Road-map, it’s of utmost importance that we plan and plant resources in a way that they be productive and at their very best. A productively utilized resource will be able to help this cause than a ‘utilized’ unproductive resource.

A productive resource is a happy resource. A productive resource is a one with the highest job satisfaction. Productivity can be measured in the long term metrics unlike Utilization that can be measured in short terms one’s.

‘Resource utilization’ is a finite game whereas, ‘Resource productivity’ is an infinite game and in this game the one who outlasts, wins.

“Productivity isn’t about being a workhorse, keeping busy or burning the midnight oil.. it’s more about priorities, planning, and fiercely protecting your time.” — Margarita Tartakovsky

The moral is to strive for productivity instead of utilization. The goal should be to track the productivity of an employee rather than the utilization.

A measure of productivity is: How much laughter do you hear around your desk? Also, what’s your teams/firms attrition rate?

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

[3] Why Agile?

[4]The Agile mindset: Doing Agile vs Being Agile

[5]The Agile Mindset — Lessons from M.S. Dhoni.

Let me commence by writing that I’m a big fan of Cricket. In-fact, it’s safe to say that Cricket has a good amount of influence on my life.

What does Agile mean? Well, the dictionary meaning of the term ‘Agile’ is to be able to move easily and quickly. Can we also infer that it means, to be fast and while being fast also be smooth at it? Now, imagine the word ‘Agile’ in your workplace. Can we infer that, when it comes to our projects/products, it means to build fast and deliver even quicker? Now, how can we build and deliver faster? Wouldn’t it require smaller goals while keeping an eye on the bigger picture? Wouldn’t it require a frequent check to know the direction that the project is heading towards? Wouldn’t it require an ability and capacity to adapt? Mr. M.S. Dhoni shows us how.

In the era prior to Dhoni captaining the Indian side, it was a norm to let the fast bowlers exploit the hard new cherry and we all agreed because it swung wild and turned batsmen square on the crease and more so, because that’s how it has always been. Every cricket playing nation followed the same routine. You have specialists at the top of your batting order to hit you in all corners of the park and you have big fast bowlers ready to break your nose and rattle the stumps. Many moons ago, Dhoni created history by doing something unimaginable at the Sardar Vallabbhai Patel stadium, Ahmedabad. India has lost a crucial toss to Australia and it was a contest for the semi-final berth at the ICC World Cup 2011. Dhoni asked the off-spinner R Ashwin to open the bowling with the hard, new and shiny ball with Zaheer at the other end. Dhoni Responded to change instead of following a Plan. Shane Watson, the in-form opener and Brad Haddin were taken by surprise. Watson found it difficult to maneuver Ashwin around with Suresh Raina at leg-slip and a frustrated Watson gave away his wicket falling cheaply for just 25 runs. India went on to win that match with 14 balls to spare and eventually the world-cup.

Dhoni built a Team around motivated individuals and provided them support they need and trusted them to get the job done.

Let’s break it down now. What did Dhoni do? Dhoni inspected and adapted. It was a crucial match for India and Dhoni just knew that Indian fast-bowlers would get hit all around the park by the in-form Shane Watson. Now, Dhoni had something which the opposition didn’t — the element of Surprise. Dhoni focused on the first issue to be dealt with instead of looking at the entire Australian line-up and trembling. Now, Watson did not have a plan to deal with R Ashwin early on his innings and consequently succumbed to Dhoni’s plan. Medium-pacer Munaf Patel bowled just 7 over while off-spinners, R Ashwin and Harbhajan Singh and part-timer Yuvraj Singh bowled their quota of 10 overs. So, how do we apply to this lesson to our workplace? We inspect the routine, we realize the issue, then adapt to the situation and trust our Team to get the job done. Trust is the keyword here. You ought to change things a bit sometimes and just mix it up. You got to think on your feet. You don’t do this every single time. You do it when none of your other ‘well-thought’ and ‘always-worked’ plans work or suspect that they won’t work. Do & be Agile.

Be ready for change — how important is this? Change is the only thing constant, remember?

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

[3] Why Agile?

[4]The Agile mindset: Doing Agile vs Being Agile

The Left brain is mostly logic, analysis, facts.

Using your left brain you:

• Inspect
• Adapt
• Focus
• Deliver
• Apply various practices
• Use numerous frameworks
• Manage changing priorities
• Demonstrate living the Agile values and principles

By using your Left brain, you are Doing Agile.

The Right brain is mostly feelings, arts, intuition.

Using your Right brain you:

• Trust
• Collaborate
• are vulnerable
• Bring joy at work
• Learn continuously
• Bring in Transparency
• Define the Agile culture
• Live and breathe the 4 values and 12 principles of Agile

By using your Right brain, you are Being Agile.

The Agile mindset is a collaboration of the Left and the Right brain put together but one must really understand the difference between Doing Agile and Being Agile. Doing Agile is easy, Being Agile is difficult.

Example: You could buy the costliest gym membership but to be a Bodybuilder you must adopt the bodybuilding Principles [eat clean, train hard, rest] and Values [discipline, dedication, perseverance]. And just like Rome, you cannot become a bodybuilder in a day.

The Agile Mindset is a journey.

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

[3] Why Agile?

The realistic answer is — on the last day of the project.

Back in the day, this model was widely used in the Construction business. It wasn’t even built for the Software industry. Since it seemed Logical, it was embraced by the Software industry and renamed as the Software Development Life Cycle[SDLC] model. This is also called as the Waterfall model as the output of one step becomes the input for the next.

Over a period of time few disadvantages of the Traditional Waterfall model were identified. They are as follows:

• High amount of risk
• Higher amount of uncertainty
• Increased time to market
• High cost of change
• Higher cost of fixing defects
• Late revenue generation as prototype cannot be released until all the stages are complete
• Not suitable for complex projects

Some of the Issues faced with Clients were:

• Many-a-times the Clients do not know what they want to accomplish until they knew what a Software can deliver.
• Clients may not be clear with what they ‘actually’ want.

• There’s a difference between what the client wants and what is delivered [Chinese whispers]

To eliminate the disadvantages of the Traditional Waterfall model and some of the issues mentioned above, Agile was introduced.

By following Agile values and principles, you can deliver high priority functionality at regular intervals. The entire project/work is divided into smaller chunks, the communication with Client is done frequently and delivered frequently. The Agile Manifesto encourages change as key to success. The minimum viable product [mvp], along with frequent releases, supports these objectives.

Below are some of the findings that state the advantages of Agile over traditional Waterfall model:

However, never forget the ‘Why’ of Agile.

“Nothing endures but change”.

Previous articles:

[1] What is Agile?

[2] what is NOT Agile?

One should familiarize oneself with the Agile values and principles and should believe in the ‘why’ of Agile rather than the ‘how’ to follow Agile.

[2] Considering Agile to be a Methodology/Framework/Process/Tool

Agile is not a methodology or a framework. Agile is a set of values and principles. Following those values and principles make you Agile. If a particular Methodology/Framework/Process helps you follow Agile, then that makes you Agile.

[3] Not wanting to Change

Admiral Grace Hopper [https://en.wikipedia.org/wiki/Grace_Hopper] once said, the most dangerous phrase is — We’ve always done it that way’. This usually means, that the Inspect and Adapt isn’t happening and you’re not willing to change.

The Neanderthals said that and eventually died out.

[4] Writing your User Stories on a piece of paper

Agile doesn’t talk about using pieces of paper / sticky notes particularly but if it serves your purpose and everybody in the Team feels benefited from writing user stories on a paper/sticky notes then feel free to do it.

A word of caution: Save paper, save trees.

[5] Using a particular tool [read: Jira, Asana] to write or track User stories

Agile doesn’t recommend any particular tool or website to write and track your User Stories but if it sails your boat and everybody in the Team feels benefited from writing user stories on Jira/ Asana/ Trello then feel free to do so.

[6] A specific way of developing software

You cannot build a software using Agile. You design a plan/process based on Agile values and principles to develop the required Software.

[7] Re-naming your Meetings: Sprint Planning, Daily Stand-ups, Retrospectives etc etc

Simply renaming your meetings to the one’s mentioned above doesn't make you Agile. One has to understand the objectives of those meetings rather than just renaming them. In-fact, understand & follow the purpose of those meetings and then call them whatever you wish.

[8] Not able to deliver usable code in regular intervals.

The whole purpose of being Agile is to deliver fast. If you’re unable to deliver fast and frequently, then you aren’t Agile.

[9] Team not having enough Latitude to self-organize

The Team that knows what to do when the sea is rough without being told what to do is that Team that will withstand any storm.

Now, how do you get a Team to self-organize? You stop spoon-feeding. You encourage them to self-organize among themselves and come up with a plan. In-between all these, you assure the Team as their Leader/Senior/Peer that you trust them with heavy artillery and will be there for them if it goes south. And what do you do when it actually goes south — You be there for them, as promised.

[11] Too much documentation

Now, Agile speaks about “less” documentation and not “no” documentation. Agile says, give precedence to Working Software over Comprehensive Documentation. This means, documentation is a must and those should be the one’s that are relevant and necessary. Also, do not fret over documentation.

[11] Not prioritizing face-to-face communication over emails and messengers

In short, please refrain from being a Keyboard warrior. E-mails are good; they’re wonderful but only when necessary.

Nothing can replace a Human interaction, a hand-shake, a pat on the back ever.

[12] Getting caught in the undertow of being Agile

Claiming yourself to be an Agile team just because it sounds fancy, is certainly not being Agile. If your Team can follow the Agile values and Principles over a period of time, then that would make your Team Agile.

Remember: It’s never the intensity; it’s always the consistency.

.. et cetera, et cetera but You get the idea, right?

Previous Article: https://medium.com/@sushant.kanchan/what-is-agile-4a7a61e4508b