In my recent article, "Project Owner = Strategic Thinking
," I began describing a focus on the various roles within the Scrum team, starting with the PO. In this article, I will focus on the development team.
Recently in a discussion with one of my customers, I heard an interesting statement, "Good enough is the enemy of great." This started ringing bells and sounding whistles in my thought process, as I began to analyze the statement and understand its hard and true meaning. I am sure most of us would often have deemed something "good enough," without realizing that good enough does not mean perfect or great. We have missed out, settled for something less.
This same concept applies to development teams. Often with these teams, we focus on the technical side of the discussion. This doesn't do justice to the role that the development team has to play in a Scrum environment.
Any development team needs, in addition to technical acumen, a good execution focus. A great technical team relies on the execution of ideas and implements them in order to derive great benefits from the system. For a development team to be successful, it needs execution focus on the following:
Compliance and process management
Planning and organization
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.
Results 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 than in going through a process. In many ways it is a good thing, as long as the desired result is honorable and the process has integrity. One could say it doesn't matter how you get there as long as you get there, but that's not good if the path has a detrimental effect on other areas, such morale of the team, ethical issues in the team, and so on.
"Result oriented" refers to a form of team strategy that is focused on achievements and outcomes. The strategy aims at balancing and satisfying the needs of all relevant stakeholders. The focus of individuals on the development team is to make things happen.
Results orientation would involve several elements. For the sake of simplicity, we will look at them as levels of approaches that an individual can achieve on a team to bring a better results, along with transparencies and the team as a whole. The levels of approaches are as follows:
Stays focused on results
Seeks to improve personal performance
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
Seeks to improve team 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
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
A traditional statement in any business is, "Your customer had a requirement yesterday, they will tell you it today, and we will deliver it tomorrow." This statement shows that we are already three days behind in fullfilling the needs of the customer.
Successful customer-focused strategy puts the customer firmly in the center of every Scrum team decision. Customers like to feel special and appreciated, so responding to them in a way that makes them feel important and valued is one way to encourage their ongoing involvement. Formal/informal methods can be adopted for eliciting some customer feedback, which is an important link in the customer retention chain.
Customers want 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 it. 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 the Scrum team.
For any Scrum team to bring customer focus into their approach, the following elements would be important:
The development team should know the needs of its customers and what they think about the capabilities of the team. The 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 processes, and discussing how they might be able to develop their own products or services to ensure that the customer's needs are met.
This might go against the idea of the Scrum, where we live by the sprint and really don't worry about the larger picture; but for any successful team, one would need two views of any system/product. They would be:
The big-picture view
The tunnel-vision view
The important element is to know is which one to apply when. Tunnel vision is important for focusing on the current sprint; the big-picture view is required for a larger understanding of the product in general.
Teams should be careful not to lose the skills or experience the project has helped them build up. They need to find formal ways of sharing their knowledge about the best ways of doing things. For example, you might create procedural guidance based on your team's best practices. Create a knowledge strategy for your development team.
This is best done by the product owner, but the development team has equal responsibility in understanding the requirements and in seeking clarification about the needs of the feature/user story (or can we say requirement). Every time the development team has a look at the user story, the following elements should be in the 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?
Analyze operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements.
The idea of the analysis above is not to identify the "doability" of the user story but more the "goodness" or quality of the user story.
Even the most ingenious invention will be a market failure if it does not meet the needs of the customer. For a development team in Scrum, the first and the most direct customer would be the product owner.
Customer involvement refers to ways that they become part of the process and the extent of their participation. This is particularly important if your team engages in 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. This is an area where the development team should guard itself and ensure that customer involvement is at the right level, not disturbing the process but providing valuable insights into the system.
By allowing customers/end users to become idea generators and cocreators 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 process. The time has come for a true customer collaboration.
For a development team, getting customer feedback is of prime importance, otherwise they would not know whether they are moving in the right direction, what changes to the approach are required, and so on.
The traditional approach of Scrum is always to use the sprint review ceremony to solicit feedback on the work performed during the sprint. With the growing needs of the customer and the 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 as a "potentially shippable software increment."
The essence of the customer feedback can be summarized this way: 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 should welcome the chance 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. If that 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, compliance and process management have gained prominence. In traditional projects, we would have a regular, defined auditing process that gives us real insights into violations of business process rules. The challenges posed by the need to implement compliance requirements in an organization call for a structured method, which may prove to be counterproductive in a Scrum environment.
The team, with the assistance of the ScrumMaster, should go ahead and define the required process for Scrum practices to be 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, and how the information from the sprint retrospective would be acted upon.
Scrum as such has a few important ceremonies and a few important documents that help the development team and other stakeholders (e.g., the PO) execute the project as needed and required. It is important to us to remember that the basic structure of Agile Scrum practices work in the area of delivering working software.
Planning and organization
Scrum projects have three 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 organizing, 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 organizes a sprint well, it results in a productive and positive experience for everyone.
For any project, one must understand the phrase, "Expect the unexpected." Be prepared to adapt or change your plans in order to meet the situation at hand. Agile itself means adaptability.
In the context of a 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 first. 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 those goals. Also, encourage team members to set their own individual goals to help accomplish the group's larger objectives. Every member should have specific goals for her task. This ensures that tasks are completed thoroughly and on time. When the smaller goals are accomplished, the larger goals usually follow.
With the pressure of having to make deliveries of working software every two weeks (or at other regular frequencies), decision making becomes a critical element for any development team. Decision making is performed by the team at regular intervals, which would be at sprint planning meeting, Daily Scrum, and sprint retrospective.
Each of the ceremonies of the sprint brings a different flavor of decision making.
Sprint planning meetings require decisions: decisions about what can be done in the given time frame of the sprint, what commitments can be made by the team to carry out the commitments. The team needs to decide, based on its availability, skills, and resources, what it can promise to the PO.
The Daily Scrum requires decision-making ability with respect to the changes in the plans and approaches that could help the team achieve and meet its commitments as given to the PO.
Finally, in the sprint retrospective, the team needs to reflect on what could be done differently and develop strategies to achieve new approaches. The basic elements of "inspect and adapt" need to be working here.
In my next article, I will focus on the ScrumMaster's role.