Good enough is the enemy of great — Development team need to have an execution focus

In the 2nd part of this series, describing a new dimension focusing on the various roles in the Scrum team, In this offering, we shall focus on Development team.

Very recently in a discussion with one of my customers, I heard a very interesting statement and that was “Good enough is the enemy of great”. This statement started ringing bells and whistles in my thought process to analyse the statement and understand the hard and true meaning of the same. Many a times, I am sure most of us would have made that statement of “Good enough”, without realizing that good enough, does not mean perfect or great, we have missed out on something and settled for something less.

This same concept applies to the development teams. Many a times with the development team, we typically tend to focus on the technical side of the discussion, this would not do justice to the role that the development team has to play and perform in a scrum environment.


For any development team, other than the technical acumen they also need to have a good execution focus. Great technical team, rely on execution of ideas and implement them, in order to derive great benefits from the system

For a development team to be successful, it would require the execution focus on the following:

Result orientation

  • Customer Focus
  • Compliance and Process Management
  • Planning and Organization
  • Decision Taking

The above elements may not follow any specific order, but all of them would be required for a development team to move from good to great


Result Orientation

Result orientation is a term used to describe “Knowing what results are important, and focusing on the resources to achieve them”

This means that the development team should be more interested in the final outcome rather than going through a process. In many ways it is a good thing, as long as the desired result is a honourable thing and that the process has integrity. One could say it doesn’t matter how you get there as long as you get there, but not good if it has a detrimental effect on other areas such moral of the team, ethical issues in the team and so on.

Result oriented refers to a form of team strategy, which is focused on achievements and outcomes. The strategy aims at balancing and satisfying the needs of all relevant stakeholders. The focus of individuals in the development team is to make things happen.

Result orientation would involve the following elements, for the sake of simplicity, we shall look at them as level of approaches that an individual can achieve in a team to bring higher degree of results along with transparencies and team in whole

The levels of approaches are as follows:

Level 1

Stays focused on results

  • Promptly and efficiently completes work assignments based on self –allocation approach
  • Aligns personal work with team/unit goals.
  • Plans, prioritizes and balances work to meet commitments, goals and deadlines.
  • Stays focused on goals despite obstacles and disruptions.
  • Compares work performance and outcomes against standards to achieve quality results.

Level 2

Seeks to improve personal performance

  • Sets challenging yet realistic personal goals in line with team/unit goals.
  • Looks for ways to improve personal efficiency.
  • Anticipates, identifies and effectively deals with problems or risks.
  • Plans for contingencies to deal with unexpected events.
  • Develops personal work plans to structure work and achieve required results.
  • Evaluates own work performance and identifies ways to improve it.

Level 3

Seeks to improve team performance

  • Uses appropriate tools, methods and criteria to regularly evaluate work processes, services or deliverables.
  • Challenges ineffective work processes and offers constructive alternatives.
  • Establishes effective team methods for assigning, managing and tracking work.
  • Develops systems to organize, track and share information.
  • Solicits and/or provides information that could affect the planning, programs and decision-making for the team.
  • Sets the expected standards and criteria for measuring success.

Customer Focus

A traditional statement in any business is that “Your customer had a requirement yesterday, they would tell you today and we shall deliver it tomorrow”, this statement shows that we are already behind by 3 days in regards of full filling the needs of the customer.

Successful customer-focused strategy puts the customer firmly in the centre of every scrum team decision. Customers like to feel special and appreciated, so responding to customers in a way that makes them feel important and valued is one way to encourage customer involvement. Formal / Informal methods can be adopted for eliciting some customer feedback, which is an important link in the customer retention chain.

Customers are looking to have their needs addressed quickly with a hassle free approach. Customers expect a quick response time.

Customer feedback, both positive and negative, is invaluable to a team, yet a surprising number of scrum teams fail to obtain this. Negative feedback does not have to be a bad thing, particularly if the customer’s view is dealt with quickly.  Put yourself in your PO’s shoes; what is their first experience with your product? Do they like it, Is there Love at first sight?

Practices of customer focus involve the establishment of links between customer needs and satisfaction and internal processes

Customers are the most important stakeholders for scrum team.

For any Scrum team to ring in Customer Focus in their approach, the following elements would be important:

A)       Customer Knowledge

Development team should know the needs of their customers’ and what they think about the capabilities of the team. Team may be able to develop mutually beneficial knowledge sharing relationships with customers by talking to them about their future requirements, their ideas, their thought process and discussing how you might be able to develop your own products or services to ensure that you meet their needs.

This might just go against the idea of Scrum where we live by the sprint and really not worry about the larger picture, but for any successful team, one would require to have 2 views of any system / product and they would be:

  • The Big Picture view
  • The Tunnel vision

The important element is to know, which one to apply when, Tunnel vision is important to focus on the current sprint and Big picture view is required for the large understanding of the product in general

Teams should be careful not to lose the skills or experience your project has built up. You would need to find formal ways of sharing your teams’ knowledge about the best ways of doing things. For example, you might create procedural guidance based on your teams’ best practice. Create a knowledge strategy for your development team

B)       Customer Requirements

This is best done by the Product owner, but the development team has equal responsibility of understanding the requirements, seeking clarifications on the needs of the feature / user story (for can we say requirement).

Every time, the development team has a look at the user story, the following elements should be in discussion:

  • Do we have adequate clarity on the requirement / user story?
  • Are the requirements / user stories conflicting?
  • Are the requirements / user stories ambiguous?
  • Are the requirements / user stories testable?
  • Analyse operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements.

The idea of the above analysis is not to identify the “Do-ability” of the user story, but more on the lines of the goodness of the user story

C)       Customer Involvement

Even the most ingenious invention will be a market failure if it does not meet the needs of the customers

For a development team in Scrum, the first and the direct customer would be the Product Owner.

Customer involvement refers to ways which in turn become part of the process and the extent of their participation. This is particularly important if your team involves a high level of customer contact, which is again a basic need of scrum, based on its manifesto and principles

More customer involvement can mean better quality, faster delivery, greater flexibility, and even lower cost. The advantages of a more customer-focused process might increase the net value to your customer. Some customers seek active participation in and control over the process, particularly if they will enjoy savings in both price and time and this is the space, that the development team should guard itself against and ensure that involvement of the customer is at the right level, which does not disturb the process and also provides valuable insights into the system

By allowing customers / end-users to become idea generators and co-creators of new products or improvements to already-existing systems, it becomes possible to move beyond the customers’ expressed needs to a comprehension of their latent or unarticulated needs.

In the near future, organizations and development teams would need to be able to create processes facilitating collaboration during the innovation thought process. The time has come for a true Customer Collaboration.

D)       Customer Feedback

For a development team, getting customer feedback is of prime importance, otherwise one would not know, if we are moving in the right direction, what changes to the approach are required and so on …

The traditional approach of Scrum was always to use the sprint review ceremony to solicitate the feedback on the work performed during the sprint, but with the growing needs of the customer, dynamic environment of doing business, the scrum concept itself now needs to scale to provide much quicker feedback so that by the end of the Sprint cycle, the customer really has something that could qualify for “Potentially Shippable Software Increment”

The essence of the customer feedback can be summarized as; when customers feel that a development team truly cares about them and what they think. When a team makes changes according to feedback, it shows that they truly listen and respect those opinions, it is important to remember that we shall welcome the change to harness the competitive advantage for our customers.

Compliance and Process Management

Process transparency is the heart of compliance and quality management. It is about how a team operates – who does what, why and when – is unclear; the Scrum team will be unable to effectively institute business controls, policies, procedures, and a system to sustain operational excellence.

In the growing space of CMMI and ISO frameworks, this subject of compliance and process management has gained more prominence than before. In the traditional projects, we would have a regular frequency defined auditing process that gives us real insights into violation of business process rules. The challenges posed by the need to implement compliance requirements in an organization call for a structured methodology, which may prove to be counterproductive in Scrum environment.

Team along with the assistance of the Scrum Master should go ahead and define the required process for the Scrum practices to get implemented, this could include the way Sprint Backlogs are defined and maintained, or how continuous integration would occur in the project, or how and where the defects as reported would be logged, how the information from the sprint retrospective would be acted upon.

Scrum as such has few important ceremonies and a few important documents that help the development team and other stakeholders (e.g. PO) to run and execute the project as needed and required. It is important to us to remember that basic structure of agile scrum practices work in the area of “Delivering Working Software”

Planning and Organization

Scrum projects have 3 levels of planning, namely: Release, Sprint and Daily Scrum. In the Sprint and Daily Scrum, the development team has an important role.

By using the skills of planning and organising, the team will be able to get a lot more done, be able to meet deadlines and be able to demonstrate a shippable product increment. If the team plans and organises a sprint well, it results into a productive and positive experience for everyone.

For any project, it is required to understand the phrase “Expect the unexpected”. Be prepared to adapt or change your plans, in order to meet the situation on hand. Agile itself as a meaning means adaptability.

In the context of Self-Organizing, Self-Managed approach, with no project manager in the scope of things, planning and organizing becomes a lot more important, as the team needs to manage the sprint themselves. Organizing a work plan (sprint backlog in our case) with a team requires frequent, regular meetings. The meetings should address the overall goals of the sprint backlog, but there should also be a setting where feedback and amendments can occur. Team members should be able to voice their questions, concerns, and ideas regarding the sprint backlog.

A sprint backlog must have a timeline that is firm yet feasible. The team should know when they must complete certain tasks and duties. Also, many tasks cannot be completed until other tasks are completed beforehand. If your team is making GUI screens, the team members in charge of design must first design the screen before the other team members can develop it. Your timeline should be flexible enough to account for any setbacks the team encounters.

Set long and short-term goals for the team. Encourage feedback from the team members to help develop the goals for the team. Also, encourage the team members to set their own individual goals to help accomplish the larger objectives of the team. Every member should have specific goals for her task. This ensures tasks are completed thoroughly and on time. When the smaller goals are accomplished the larger goals usually follow

Decision Taking

With the pressure of having to make deliveries of working software every 2 weeks or at regular frequencies, Decision making / taking becomes a critical element for any development team. Decision making / taking is performed by the team at regular intervals, which would be at Sprint planning meeting, Daily Scrum, Sprint retrospective.

Each of the ceremonies of Sprint brings a different flavor of decision making / taking.

Sprint planning meeting requires decisions. Decision of what can be done in the given timeframe of the sprint, what commitments can be done by the team, to do the commitments; the team needs to decide, and based on its availability, skills, and resources what can be promised to the PO

Daily Scrum requires the decision taking ability with respect to the changes in the plans / approaches which would help the team to achieve and meet its commitments as given to the PO

Finally in the sprint retrospective, the team needs to reflect on what can be done differently and how it can achieve the same; they need to develop strategies to achieve the new approaches. The basic element of Inspect and Adapt needs to be working here.

In the next series of this blog, the last of the current series, we shall focus on the Scrum Master role in Scrum


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s