Insights on Definition of Ready (DoR)

The Definition of Ready (DoR) and the Definition of Done (DoD) are checklists of the work that must be completed before a product backlog item (PBI) can be considered to ready for release.

The Definition of Ready (DoR) defines the ready state. In simple terms, a epic/user story needs to meet some criteria (or conditions) before it can be picked up for a release/sprint. The DoR collects all the conditions necessary for a user story/epic to be developed in the current sprint/release.

The  PO/PM is accountable and responsible for the DoR that must have all details required by the organization, and description of the epic/story in consultation with the team.

A Definition of Ready (DoR) Defines Pre-Conditions.

A well defined and DoR compliant epic/story will help everybody associated with information that will be useful not just for the development team but also the stakeholders, marketing and sales people.

The stakeholders will benefit from the DoR by knowing the business value/ROI expected from the epic.

The sales people will be delighted to know the expected value/purpose for the customer. That will help them in their sales pitch.

Every required detail should be in the Epic/Story before the team can start grooming (not commit) the work item before they pull it up in sprint planning.

Focus on the description (canonical format), acceptance criteria, estimates, size, start date, due date and all other details that apply.

Backlog grooming: The focus here should be more on creating not only a strong backlog but also a healthy one. Hence, the DoR is important.

Grooming the product backlog should ensure that items at the top of the backlog are ready to be moved into a sprint so that the development team can confidently commit and complete them by the end of a sprint.

The backlog grooming focus should be more on the health of a strong backlog rather than the immediate next sprint.

What DOR means…Accountability

Product Owner/Product Manager

• Add a description – Description should be in the canonical format – Either, Given-When-Then, or As a Role-What-Result.
  • For user story- It will be interesting to note that there are tools like cucumber, gherkins, etc. that can automate acceptance tests based on the canonical format. Hence, it is very important to follow the approach.
• Prioritize the Epic/Story – (use prioritization techniques like WSJF (weighted shortest job first), Customer demand, Ranking, MoSCoW, Five Why’s, KANO, etc.)
• Assign a high-level Size for the Epic. (the context of size here is to give it a number (Fibonacci series), or t-shirt size (S, M, L, XL, XXL) and not estimated effort, time)
• What value is it adding to the product –
  • Is it an organisation initiative?
  • What is the customer perceived value? – This information is important for the stake holders and sales people.

What DOR means…Consulted

Architect

• Scope and refine the epic/story based on technical investigation.
  • Carry a feasibility study and document possible approaches to develop the epic/story (POC, Spike) Note: POC and Spike are not the same.
• Can assign a preliminary estimate to the Epic/Story. (the context of estimate here is to give it a number (Fibonacci series), or t-shirt size (S, M, L, XL, XXL) and not limited to the estimated effort, time). The development team has the final say on the effort estimate.
• Highlight any architectural risks/challenges.

What DOR means…Responsible

Development Team

• Understand the description, acceptance criteria and scope.
• Refine the preliminary estimate in consensus with PO and architect.
• Give an Estimate for the story (effort estimates should be based on– Complexity | Uncertainty | Dependency) . (The estimations can be done in the sprint planning, better if done during the backlog grooming)
• Assign an owner and commit. (Should be done in the sprint planning)
• Create tasks for each story. (Should be done on the first day of the sprint. If possible, do it during the sprint planning itself)

There are different thoughts on creating tasks. But, it has been proved in the product organizations that creating tasks will help in getting more clarity in the burn-down charts and thereby help in tracking the correct progress. However, there are other matrices to track the progress that should be considered once the team becomes mature with this process. There are more chances of team getting corrupted when they start understanding the system better and, over a period the velocity chart shouldn’t be the only data to rely for value output.

What DOR means…More details

Capture all engineering level discussions, constraints, dependencies, underlying assumptions & the finalized approach. Highlight any engineering level risks/challenges with other discussion points.

Tip for creating a healthy and strong backlog

Conduct JAD (Joint Application Design, or Joint Application Development) sessions, if needed.

• Simplify — consolidate months of meetings and phone calls into a structured workshop.
• Identify — issues and participants.
• Quantify — information and processing needs.
• Clarify — crystallize and clarify all requirements agreed upon in the session.

What is Definition of Ready DoR for an Epic/Story

Definition of Ready for an Epic

Detailed Appropriately

• Dependencies are identified and no external dependencies would block the PBI (Product Backlog Item) from being completed.
• Details are sufficiently understood by the development team so it can make an informed decision as to whether it can complete the PBI.

Emergent

• The feature shouldn’t be static. As the project progresses more information (description/user stories) can be added.

Estimable

• The items at the top of the backlog have more accurate estimates.
• The lower priority items are estimated at a high level and can be re-estimated as the team gets more information.

Note: Sizing – Not all XXL size will require the same effort. Similarly, not all S or M size will require any less effort. One size doesn’t fit all. Practice relative sizing.

Prioritized

• Business value is clearly articulated. •Performance criteria, if any, are defined and testable.

Definition of Ready for User Story

Independent

• The work item should be independent (self-contained and possible to bring it to progress without any dependency on other work items or external resources).

Negotiable

• Should have enough room for discussion regarding its optimal implementation

Valued

• What value it provides to the user, should be clear.

Estimated

• In story points (note the story points is a unit-less unit, i.e., it may not mean 1 point = 1 day, or a couple of hours).

Note: Estimation – Not all XXL stories will have higher story points, and not all S, M   stories will have less story points. It is based on the level of Complexity, Uncertainty, Dependency

Small

• The PBI (Product backlog item) must be estimated and small enough to be completed in one sprint.

Note: Slicing – there are various techniques – Vertical, SPIDR (Spike, Path, Interface, Data, Rules) – whichever applies for the story can be used.

Testable 

• Acceptance criteria are clear and testable.

---

We will discuss Definition of Done (DoD) in the next blog.

Advertisement

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.

• 

Change?

“There is an expiry date for all. No body and nothing are indispensable. There are no guarantees to anything. Nothing lasts forever.”
All that exists has to perish and go back where it has come from. That’s the only constant. That’s nature. Everything that is created has an end and MUST have an end or it becomes monotonous and loses value. If there is no end then there is no room for the new. If we want a change then we have to change that which is now. There is no such thing as forever. If there is then it is death. I am yet to see one who can prove that life is forever, it is death that is forever. Thoughts change, feelings change, responses change, ideas change. The word idea can be treated as a short term for i-Dream / i-Death. The death of the old and the birth of the new becomes an ‘idea’. 

‘I’ has to die to give rise to the new. The ‘I’ is the ego. Let it die, or better,……….. kill it!

‘We change the world by changing the way we perceive the world, the way we think about cause and effect, by altering our beliefs of true and false, right and wrong’.In this material world we believe in buying the latest. Why? Because we all want a change. We get bored with the new and again want a change. For this simple reason even the furniture re-arrangement in our house after a while makes the room look new, but then after some time that too becomes old and needs a change. Don’t be that rickety old piece of furniture that eventually gets replaced. Be the change!

Our conditioned ways of looking at things prevent us from taking the plunge, or allow anybody else to take the plunge.

We are so attached and used to our designations and comfort zones that we do not want to let go for the fear of losing all. We are so much obsessed with power that we forget to empower.

Transformation is the need of the hour. Do introspect and see if you value change, or you are the bottleneck!

In the software world, what was new yesterday is legacy today. Keep upgrading keep learning. Embrace change rather push back. Change or be prepared to be changed.

Don’t fake it, if you don’t have it!

That reminds me few lines from the poem ‘IF’ by Rudyard Kipling –
If you can make one heap of all your winnings

And risk it on one turn of pitch-and-toss,

And lose, and start again at your beginnings

And never breathe a word about your loss;…

‘What is the theory behind what we do? Is it really about what we want, or need? Or, has it gone untested for so long that we no longer question it?’

In the land of opportunities that is the United States; It took 43 presidents before the change;
44th was the president who was not a white American- Barrack Obama.

Who wants a change?

The magic lies in changing the way we think in order to change the way we live.

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… 🙂

• 

Decision Dilemmas- All about making and taking a decision

At every point in life we have to take decisions. Those decisions, though ours have an impact on many around us. Our friends, family, society, nation, economy, and politics; all are affected by our decisions. So, what exactly is a decision? Is it something that can be ignored or, it is something that is the cause for everything happening around us? Taking a decision also means not taking a decision. Read ahead and you will know.

Decision:

• The act of making up your mind about something.
  • This can be an opinion about somebody or something.
  • Opinion is not judgment – Opinions assist in judgment.
• Decide to do something.
  • To decide to do something also means to decide not to do something.

Example: I decide to start my day early. Meaning, I decide I will not wake up late. It also means that I decide to sleep early…and so on…

Example: We have to decide on which car to buy, where to invest, where to construct house, and so on…

• Decisions can vary from simple ones to complicated and serious decisions.

Types of Decision

• Good Decision.
• Bad Decision.
• Incorrect Decision.

What is the difference?

• Optimal Result = Good Decision.
• Average Result = Incorrect Decision.
• Failed = Bad Decision.

Case study – Starting a Venture

• Decision to start a business – Good decision, can be incorrect or bad decision.
• Decision to quit Job – Good decision, can be Incorrect or Bad decision.
  • Optimal Result – Good Decision – If the business grows and becomes profitable.
  • Average Result – Incorrect Decision – if growth becomes stagnant and eventually stops.
  • Failed – Bad Decision – Would have been good if… Best reason to learn from the failure and start all over again.

Examples of some famous decisions

• Mohandas Karamchand Gandhi decided that India was to be freed from the Queens rule. Not that he was the only one, there were many but his means to free India from the Queens rule was different and shameful for the British that they had to quit.
• Dhirubhai Ambani – wanted to create wealth and he did, not only for himself but for all.
• Larry Page & Sergey Brin wanted to collect and make available the entire information available in the universe. Their college project -PageRank resulted in Google – literally replacing the Oxford dictionary.
• Steve Jobs decided he was wasting his time in college studying subjects that did not inspire him, so he dropped out and took up a calligraphy course.
  • Result – Apple Inc – Mac PC, iPod, iPhone, Pixar studios and the numerous creations that has changed the way we live.
• Bill Gates decided to drop out from college to do more of what he liked doing.
  • Result – Microsoft – his decision opened Windows for us to see the world.

Any decision; whatever the result be -Optimal, Average or Failed; will never take away the value from the decision.

Value

• It’s the depth of the decision.
  • Why it was taken – Purpose.
  • When it was taken – Situation.

Factors influencing decisions

• Family – Upbringing, relatives, elders.
• Society – Cultural, religion, political.
• Education – Level of education – it’s not about being literate – it’s about awareness.
• Experiences – All through our life- personal and professional.
• Hear say– Gatherings, meetings, get-togethers.
• Peers – Colleagues, friends.

Few examples of the decisions we make, take – Decide!

• Decision is needed at every point in life
  • Family decision.
  • Education decision.
  • Career decision.
  • Decisions that are good for one may/may not be the same for all.
  • Decisions can have an impact on one or many.
  • Decisions can be good for some, bad for few, and average for others.
• No decision is Good decision or Bad decision, it’s the value of the decision. If the result is anything other than Optimal, the decision must be re-worked.
• Decisions are only choices. Choices make who we are and who we become eventually!

Ownership

Own your decision. It’s the best and you are the best judge.

Blink! Think! Decide!

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.

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.