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.

• 

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!

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.

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

4 L’s Retrospective…

There are different ways you can do a retrospective with your teams. Choose the one that will engage your teams and help in identifying few action items that will benefit the teams and in turn the organisation. In this blog we will discuss the 4 L technique. Initially developed by Mary Gorman and Ellen Gottesdiener, it is a simple and popular technique.

What?

The Four L’s is a classic exercise that can be used in agile retrospectives. It helps your teams to look for things they Liked, Learned, Lacked, and Longed For in their iteration, and to take actions based on their shared insight on how they are performing as a team.

As with all retrospectives, 4Ls should be timeboxed. Depending on the size of the team, 30-60 minutes should be enough. If you are doing it for the first time, then allow up to 120 minutes.

The 4 L format can be a great technique to gather data or brainstorm on ideas, etc. It can be a great facilitation tool for conflict resolution, ideations, decision making, etc.

When?

The questions might be subtle but by moving away from the traditional agile retrospective and allowing people to be more engaged from a “heart and mind” perspective can switch up people’s thinking and open-up new insights

Also, be observant and cognizant of the team temperament. There are times your team members will not want to discuss their challenges openly but, talk about those during their water-cooler discussions. Be very attentive and full of empathy for your team. Know that we all are human beings and not machines. We deal with machines and we discuss with people. 4 L is one of the ways to do it.

As an Iteration Manager it is very important for you to know your team temperature. You are one of those leaders who have the responsibility of leading your teams to victory while ensuring that even the new entrants in your team get enough opportunities to participate in the victorious journey. It is no fun to reach the goal with few star performers instead of reaching the goal with everyone involved in the journey. The focus should be on creating a star team (cross-functional) rather stars in a team.

In short encourage your team to:

• Highlight the positive (liked & learned) as well as the negative (lacked & longed for)
• Think mostly from a factual (what happened) perspective, rather than an emotional perspective.

More details…

The 4Ls retrospective is designed to get people to share their thoughts as part of being agile and with the aim of continuous improvement. By asking these questions, it can help open-up the team in to sharing their thoughts, bring out new ideas and foster a sense of being heard. It is based around the following key themes:

• Liked: What did the team really enjoy about the sprint? In particular; what went better than expected? Emphasize on the positive.
• Learned: What new things did the team learn during the sprint? These can be technical things (like the importance of unit testing) or, nontechnical things (like a new and effective way to keep a key stakeholder informed). It can also be about new ways of doing things. It can be around technology, process, software delivery frameworks, etc.
• Lacked: What things could the team have done better during the sprint? What seemed to be missing from the last iteration? This might be something that was unclear or needed to be implemented to ensure that things continue to run smoothly.
• Longed For: What things did the team desire to have during the sprint that were unavailable? Again, these can be technical (like the need for a continuous integration server) or nontechnical (like the desire for more face time with the stake holders).

You need:

Post-it notes, flip chart paper, white board, pens etc.

Process:

1. Hang four posters, one for each L, around the room, titled appropriately. Or, use a white board and divide it into four quadrants. One quadrant for each L.

4 L- Quadrant on white board

• Ask people to individually jot down what they Liked, Learned, Lacked, and Longed For – one per sticky note. When the time is up (3-4 minutes), they silently place their notes on each poster.
• Divide the team into four groups; assign an “L” poster to each group. They read all the notes, cluster as appropriate and identify themes.
• Each group reports out on the themes.
• The entire team (all four groups) then decides how they might use the data. Identify the action items. Share the outcome with the team and stake holders, if required.

How we did it?

Action

Ask each team member to add what they think under each of the four questions. This is best done independently. This process might be best done anonymously in order to help surface any issues which might otherwise not come out. They can indicate when they have finished, or you can set a timer so that you know when to move onto the next stage.

Brainstorm

Scan the ideas for common ground and have a quick discussion. Drag and drop related ideas to combine them for easier voting. Team Retro can also automatically suggest ideas that are similar, saving you and your team valuable time.

Voting

Ask people to independently vote for what they would most like to discuss in the meeting, or items that they feel are the most important. You might want to have 4 votes for example so that they select one under each topic. We used dot voting.

Votes can be tallied for the Discuss stage.

Results (Discuss and identify the action items)

You can now discuss the top voted ideas.  Walk your team through ideas one-by-one and keep the conversation focused.

Create action items based on discussions, assign owners and due dates that will carry through for review at the next retrospective.

Pizza… 😊

Spend the final few minutes to allow the team to appreciate each other and share their thoughts. That will encourage the team to speak up in groups without being overwhelmed.

Researched by- Nabarun Paul, Iteration Manager at Tavisca, A cxLoyalty company                                   

Mother-in-law syndrome in the Agile world

Mother in law is spoiling the family life! Managers are spoiling Agile Team!

“Monster in-Laws:” A Leading Cause of Divorce. In the Agile team context this causes for attrition.

An article titled “Divorce Causes: 5 Ways to Destroy Your Marriage” in the Huffington Post states that in-Laws can be a leading cause of divorce. Author Francesca Escoto writes, “how spouses relate to the in-laws is a strong predictor of marriage longevity. A man who gets along with his wife’s parents is wise — his chances of a strong marriage increases by about 20 percent. Women who get along with their in-laws actually have an increased probability of divorce, by about 20 percent.” 

What can we do about it ? We need them but they should not break the family.

In an Agile Team/Family, the manager is like the mother-in-law! in the Agile world they do not have much to do, because they have retired from the active family life, or lets say delivery role. This delivery role is managed by the Product owner and Scrum Master.

But, managers like mother in law is interfering in every course of action.

Have you seen such instances in Agile projects where the manager is hovering around the scrum team?

Mothers-in-law are known for being, judgmental, critical and overbearing. They don’t want to leave the control. For them, you are still kids and cannot decide for your good. In Project team also Manager could be the same.

She is always right, without exception. Which means that she’s never wrong. She’ll never admit being wrong, and she will never apologize for anything. In her opinion, you (and possibly your spouse) are the only person to blame. Similar situations can be seen in the Agile Team.

To establish her dominance she will expect you to please her. That would require you to appear at every family event, to learn her way of cooking, cleaning and just about everything else under the sun (because her way is clearly better). And, if you fail to do any of those, you are doomed! and she has a right to complain about you to anyone who’ll listen. Similarly with the Agile Team, the Manager does exactly the same and the escalation goes to the senior leaders.

If you are still not kneeling to her will, she will move on to heavier artillery. She will start a smear campaign in her community, trying to turn everyone against you. If she succeeds, those people will start putting pressure on your husband to leave you, saying that they’re just “worried about him” and they “want him to be happy.” Similar things can be found with the Agile Team, where Manager will be doing exactly like this and eventually the husband/scrum team member may leave.

Don’t try to mediate your son’s marital disputes. Let them solve their own problem. In Agile team, let the team members solve it, managers don’t have to jump into all these to become an hero. Managers are already heroes, now it’s time for the team to become one.

Don’t rearrange your daughter-in-law’s house. Clearly the coffee mugs should be stored in the cabinet over the coffee maker. Any idiot can see that. But it’s not the Mother-in-law’s kitchen. So, Mothers-in-law don’t decide where the coffee mugs go. In an Agile team, the team decides everything with the help of PO and SM.

1. Fold daughter-in-law’s laundry without her permission,
2. Buy clothes for daughter-in-law that only mothers-in-law would wear,
3. Think daughter-in-law is perfect,
4. Enter daughter-in-law’s bedroom without knocking,
5. Offer unsolicited advice,
6. Show up unannounced,
7. Criticize daughter-in-law’s cooking.

All these activities can be mapped to Agile team context where Managers are getting into team comfort zone and spoiling the self-organized culture.

Many of the items on the list are considered faux pas in any situation. They are a hundred times more egregious when put in the context of a mother-in-law – Manager)/daughter-in-law (SM/PO) relationship. 

How to Manage her, or Managers

What Scrum Masters can do for the Agile team ?

a) Respect her different viewpoints. Even if you don’t agree with what she has to say, listen to your mother-in-law. Don’t immediately write off what she has to say. Hear her out (even if you feel it’s ridiculous) and let her know you’re listening. You don’t have to agree to anything.

Respond neutrally by saying, “Okay, I’ll consider that” or, “Thanks for your input.”

If she puts you in a difficult position, defer to your spouse. Say, “I don’t want to answer right away. Let me talk to my spouse first.”

b) Use humor. Deflecting criticism, or other awkward interaction with humor can deflate conflicts and put everyone at ease again. Whether the situation seems tense or she’s making things difficult, a little humor can go a long way.

c) Work through your own feelings about your mother-in-law. Are you able to put yourself in her shoes occasionally and see just where some of her so-called interfering or judgmental behavior comes from? She values the person you’re married to, so there must be something good inside her!

 – Keep in mind that whatever your feelings, your mother-in-law remains one of the most important people in your spouse’s life. Be sure it’s not your own untamed jealousy causing problems.

– If your relationship with your mother is strained, or difficult consider whether that is affecting your relationship with your mother-in-law. Remember that they are different people, and you can have a different relationship with each one.

d) Create some ground rules. If you live with your mother-in-law, establish some ground rules for living together. If you know there are things that might cause conflict, talk about them beforehand and make sure everyone understands the rules and why they are in place

e) Make compromises. You and your mother-in-law will inevitably disagree on certain things, especially when living together. Choose your battles and decide what things you can tolerate and what things you need to be firm about

f) Create mutually-agreed boundaries. Both you and your mother-in-law may enjoy having your own space and ways of doing things. Ask your mother-in-law how you might make her comfortable while enforcing your own needs and expectations. As long as your boundaries don’t conflict, try to respect her space and independence.

g) Look for the good she does and praise it. Look for the good things about her, not just the bad. If she’s always cleaning despite you telling her not to, thank her for her care and contribution. Find the positive ways she adds to your life, your partner’s life, and even your kids’ lives. If possible, do this in her presence and be genuine

h) Talk about how she makes you feel. If you’re in conflict with your mother-in-law and it’s not resolving over time, or on its own, it’s time to talk about it. If she tends to criticise your marriage, or your parenting, let her know how this makes you feel. Be kind and honest and tell her what you’d like instead. Aim to find resolutions to your problems.

Author: Chandanlal Patary. 

Share your thoughts in the comments section.

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

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

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

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

1. Build Trust

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

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

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

Trust has two dimensions – Character and Competence.

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

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

2. Psychological Safety

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

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

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

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

3. Domain and Technical Expertise

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

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

4. The Scrum Master Role Goes Beyond Facilitation

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

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

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

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

5. Be Aware of the Big Picture

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

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

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

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

Conclusion

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

Co-authored by Anusha Kalvala

SCRUM Values: Story from Panchatantra

There lived four friends in a certain town. Though, all of them were young learned Brahmins, one of them was a complete ignorant in matters of learning but had good common-sense. The other three were very learned in matters of the Holy Scriptures, but lacked common-sense.

One day, as the four friends met, they decided, “The scholarship that we have over the Holy Scriptures is no good, if we cannot use it to impress the king, or otherwise to earn money!” 

They decided to travel, in order to earn a living using their learnings. But, the fourth friend was not learned, so they thought of leaving him behind. They agreed, “What good is common-sense? His talents would not help in earning money, so let’s leave him.” 

After much pleading by the fourth Brahmin, the other three decide, “It will not be correct to behave like this to a dear friend, let us take him along. We should also share a part of our earnings with him!” 

As decided, the four started their journey. As they were travelling through a jungle they noticed the bones of a dead lion lying on their way. 

One of them said, “Let us start using our scholarship! We have a dead lion in front of us. Let us test our scholarship, and try to bring it to life!” 

They are Open and transparent in thei decision making.

THEY ARE COMMITTED TO EXERCISE THEIR KNOWLEDGE

While the three Brahmins agreed, the fourth Brahmin did not like the idea. But, his preference was ignored by the other three, and they started theholy rituals.

One of the Brahmins collected the bones of the lion and using his scholarly education, created a skeleton of the lion. 

The second Brahmin used his expertise to cover the skeleton with flesh and skin. 

As the lifeless lion stood in front of them, the third Brahmin initiated the rituals to put life into the lion. 

They are all committed to do their work but  that was foolhardy commitment

The fourth Brahmin was alarmed, “O friends, if the lion comes to life, he will kill us! Please stop what you are doing!” 

The fourth Brahmin was focused on his survival. The other Brahmins were focused to exercise their talent and they were committed to do so.They were courageous to accept the consequence.

The Brahmins ridiculed him, “After reaching so far, are we going to waste our knowledge? You say so, because you are jealous of our scholarship!”

They did not exhibit any respect to their team member.

The fourth Brahmin knew that there was no point in arguing with them. He pleaded, “Please give me a moment. I wish to climb the tree nearby before you infuse life into the lion.” 

He started climbing up a tall l tree, and could see from above the third Brahmin using his scholarship, to put life into the lion. 

As soon as the lion came to life, it noticed the three Brahmins, who were celebrating the successful implementation of their education and talent. 

The lion immediately pounced on them, and killed them. 

The lion was also committed!

The fourth Brahmin could do nothing but wait till the lion had gone. Then, he climbed down the tree and returned home alone. 

Fourth Brahmin demonstrated all the scrum values.

He showed Openness and Courage to challenge their decision, he respected their decision.

He was focused and committed to warn them and save everyone’s life.

The fourth Brahmin is the scrum master, he has shown courage, he was committed and focused to help his fellow team members. But, as they did not show any respect, he could not do much to save them!

If all these team members were trained to understand the scrum values, their life could have been saved.

In the Spirit of Business Agility Transformation

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

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

The journey begins with leadership

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

Optimization at all level

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

Measurement

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

Kaizen(Continuous improvement) and Kaikaku (Radical change)

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

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

Agile is not ad-hoc

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

One size doesn’t fit all

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

Agile requires more discipline than we think

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

Beyond traditional leadership

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

Summary

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

Author:

Ramesh Manickavel, Director, Agile Program Management, CA Technologies

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.

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!