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

In the 2^nd 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

Product Owner = Strategic Thinking – A new dimension, a new thought process

 

We all know that Agile Scrum has 3 and only 3 roles to play for … namely the Product Owner, Scrum Master and the Development Team, all of them put together we have a Scrum Team in place.

Each of these  3 roles have specific elements and responsibilities to execute in order for the product / release to be successful and ensure that the agile scrum practices are well implemented in the given space of things that this team would do.

To see things in a different light, For each role, I have provided a high level element to be associated that would typically define the role and related responsibilities of the same (See diagram attached)

• Product Owner = Strategic Thinking
• Scrum Master   =  Influencing Ability
• Development Team = Execution Focus

Shall be taking each of the roles and approaches a series of ideas to be discussed in the coming blogs of mine …

We shall start with the Product Owner.

At a larger level, we expect the Product owner to own the product backlog, prioritize the product backlog items along with the stakeholders, guide the team in discussions of the user stories, provide clarity and answer queries of the development team to help them understand the requirements and needs of the product and so on …. But somewhere the focus has become very tactical rather than a strategic one, We are all focusing on the current sprint and trying to make it a success by ensuring all the right ingredients are in place for the team to deliver.

But a good Product Owner should always be having a Big Picture view along with the tunnel vision, The tunnel vision is to be used for the current sprint in question, whereas the Big Picture view is the larger approach and broad based thinking that the PO should be involved in and directing the system to move in this direction. For the larger system, we focus on 4 elements that PO should concentrate on:

• Business Acumen
• Vision & Purpose
• Deal with Ambiguity

 General definition of Business acumen is keenness and quickness in understanding and dealing with a business situation in a manner that is likely to lead to a good outcome. The term “business acumen” can be broken down literally as a composite of its two component words: Business literacy is defined in Business Literacy Glossary as “the knowledge and understanding of the financial, accounting, marketing and operational functions of an organization.”

A strictly literal definition would be “keenness and quickness in understanding and dealing with a business situation.”

In practice, PO with business acumen are thought of as having business ‘sense’ or business ‘smarts’.  They are able to obtain essential information about a situation, focus on the key objectives, recognise the relevant options available for a solution, select an appropriate course of action and set in motion an implementation plan to get the job done.  When they discover that changes are required to adapt to unforeseen circumstances, they make the adjustments as necessary and keep the activity moving forward.  They are more often right than wrong in their assessments and choices and are admired by others both for their acumen and business success.

People with strong business acumen use an explicit or implicit business framework to ensure completeness and integration as they assess a business situation. This links to the objectives of key stakeholders, the competitive strategies required for success, the people and activities needed to produce the products and services, and the business processes that support a PO’s ability to deal with the complexity.

Business acumen also requires a thought process that ensures a focus on critical factors, an appreciation of the future consequences of actions taken today and the recognition that future activities require constant monitoring and adjustment when things don’t go according to plan.  These three ideas are summarised by the terms mindfulness, sense-making and resilience.

Why do we think that a PO should have the necessary Business Acumen? The captain of the Agile Scrum flight should be / would be the PO, it is under his / her direction that the decisions are taken and implemented. As the PO owns the return on investment (ROI), it is important that he / she has the relevant business acumen to take decisions, influence decisions at the higher management level and ensure all the necessary approvals with respect to budgets, resources and infrastructure are provided with to the development team.

Understanding the MMF (Minimum marketable feature) would help the PO to prioritize the Product backlog items. Why is MMF important for this, well this would guide the PO as to what is the market expectation from the product, what would be the USP of the product, How the features of the product has to be conceived that would provide the high level of ROI to the system

Important is for the PO to understand where and when a tunnel vision should be applied and how a big picture view should be utilized and drilled into a tunnel vision.

Dealing with Ambiguity

What does ‘dealing with ambiguity’ mean?

The competencies – As a Product Owner one would need to able to do and demonstrate the following:

• Tolerate and mange change effectively
• Shift gears/change course quickly and easily
• Decide and act without having the total picture
• Tolerate situations where things are up in the air
• Tolerate and be comfortable with risk and uncertainty.

Leadership, ambiguity and resilience

As a PO, not only do you have to deal with ambiguity but you also have to be resilient and, more importantly, demonstrate and exemplify resilience to team and organization. The two go hand in hand.
Resilience can be defined as  ’bounce-back-ability’, and the competencies (they are all a little different) are generally something like:

• The ability to deal effectively with pressure and stress
• The ability to bounce back from disappointment or setbacks
• Ability to remain optimistic and positive in uncertain, new or complex situations
• The ability to show and maintain strong leadership in uncertain situations.

Product Owner may feel uncertain, but one must be able to show that they are strong enough and know what you’re doing to others, who in turn  will also be dealing with uncertainty and, probably, the same ambiguous situation from another angle. You need to be sure-footed and make them feel that they are in safe hands.

On this front , the PO’s role becomes important with respect to cancelation / termination of sprint or re-defining the prioritization of the PBIs or when to schedule a formal release to the market / users / production. In such situations, it is expected that the PO would have a clear head and with high level of clarity build-in for taking adequate and correct decisions, as they would in turn impact the system

Vision and Purpose

The way we see it, the purpose of the PO is to answer the question “Why are we developing this product?” On the mission statement, the PO would have the ownership to answer the question, “How will we achieve this?” PO has a purpose to enhance the overall quality of product and well-being of team which works on the product.

Strategic Planning 

Change is an essential component of strategic thinking and planning. This involves moving the organization or program forward to create or change something. Some plans are created out of the need for the organization to move in a certain direction, and other plans develop organically. Mission and vision statements will be important to help communicate the goals of the plan to team and other stakeholders.

PO should emphasize the current mission statement to team, which clarifies the purpose and primary, measurable objectives of the product success. A mission statement is meant for team  and other stakeholders of the organization.

Strategic plans may involve changing the mission statement to reflect a new direction of the product. Highlighting the benefits of the change and minimizing the confusion will help the team and the stakeholders buy into the change.

In the next series of this blog, we shall focus on the Development Team

Name(required)

Email(required)

Website

Comment(required)

Submit

Δ

Are we driving a CAR with 3 Mercedes tyres and 1 bi-cycle tyre?

Are we driving  a CAR with 3 Mercedes tyres and 1 bi-cycle tyre?

Sounds interesting as a title of my new blog.

But have we realized this happens every day in our working career. What does this mean? Why are we saying this in this manner? By the way who is the bi-cycle tyre? Oh man too many things at the same time.

A number of organization start to implement Agile and related practices, without realizing why they want to adopt agile, what are the potential benefits of the system, Is Agile really going to work for them, or it is just a new buzz word in the industry that one should be adopting. I recollect not so long ago, I had an opportunity to provide consulting for Agile implementation. On day 1 when I met the sponsor of the initiative to understand the need for agile to be implemented, I got a very strange answer … “When every one on the street is doing agile, we also need to be on the same band wagon”. It was a major set back for me, before it dawned to me, that is the real world for you.

So many projects, so much mismanagement. Indeed, even with project management software, IT projects often wind up taking longer (much longer) than planned and costing more than budgeted.

Why do good projects go bad? Here is the  list of  Common Agile Project Management Mistakes — along with ways to avoid these often time-consuming and potentially costly problems

Not Assigning the Right Person to perform the role of ScrumMaster. “Typically during resource allocation, most of the effort is focused on finding the right resources other than finding the right Scrum Master. Indeed, too often “Scrum Master”  get picked based on availability, not necessarily on skill set.” However, an inadequately trained and/or inexperienced Scrum Master can doom a project.

Failing to Get Everyone on the Team Behind the Project. Too often, projects are doomed to fail because they didn’t get enough support from the departments and people affected by and involved in the project.

Either Scrum Masters:

• Didn’t make clear what everyone’s role was.
• Didn’t describe the personal payoff everyone would get when the project was completed successfully.
• Didn’t tell how team’s contributions to the project would be evaluated.
• And/or failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine (meaning the old method of traditional project management)

Putting Too Many cooks at the same time:. “Most managers think that they can get more done by having a lot people in the project at the later date, but in reality, it’s counterproductive,” “Multitasking slows people down, hurts quality and, worst of all, the delays caused by multitasking cascade and multiply through the organization as people further down the line wait for others to finish prerequisite tasks.” When the plans are made, the management would never ever provide all the right resources to the project, Interestingly my observation is that they apply divide by 2 theory and at the dying moments of the project, extra resources would be added to create more confusion and chaos. Not sure why this standard theory is working across the globe always in majority of the projects

Lack of (Regular) Communication/Meetings. “Communication is the most important factor of successful project management, “Without regularly and clearly communicating, the project will fall apart.”. Infact the very manifesto of agile states that communication is the most important factor for project success
Not Being Specific Enough with the Scope/Allowing the Scope to Frequently Change. “Any project that doesn’t have an ultra-clear goal is doomed, scope change is one of the most dangerous things that can happen to your project. If not handled properly it can lead to cost and time overrun.” Even something small, like changing the colour of a logo or adding a page to a website might cause unexpected delays. One should always be worried why this element is happening in Agile projects, where the change is to be welcomed, The problem as I see is that the management is not aware of the Agile principles and lifecycle approach.

Providing Aggressive/Overly Optimistic Timelines. “The intentions are noble, as Team and SM often trying to keep their clients happy, but missing deadline after deadline will only lead to distrust and aggravation on the part of your client.” Not sure as to why Sr. Mgmt would provide these timelines to the customers and clients, when the team is supposed to do the work, The team is never taken into confidence when projecting the timelines. Are we doing estimates just to satisfy the requirements of ISO / CMMI audits / appraisals
Not Being Flexible. While you may think of your project plan as your bible, “telling you what needs to be done, by whom, and when to do it to get to your goal…don’t hesitate to listen to new information and suggestions that come up along the way, It’s good at various intervals to step back and take a fresh look at the overall project, review how things have gone so far, and how you can improve your future work based on what’s already changed along the way, just be open to suggestions if they help the project. This is the place where the retrospective of the agile projects would perfectly fit in. They need to be practices and implemented in true sprit of the game, rather than just pay a lip service.

Not Having a System in Place for Approving and Tracking Changes. “Often, success or failure of a project hinges on the changes that occur after it begins, However, all too often, there is no system in place for approving and tracking changes. Having a clear process that must be followed is the best way to ensure the pertinent details — how much it will cost, why it is necessary, the impact on the overall project — are known before the change is approved. It’s also extremely effective for auditing performance during and after project completion.”

Micromanaging Projects. “Don’t babysit, It’s very common for budding Scrum Masters to treat their job like an enforcer, policing the project team for progress and updates. Instead of babysitting the project team, let it be known from the start [i.e., the kick-off meeting] that there will be regularly scheduled updates for the duration of the project. This lets your team know that status updates and progress are expected from them weekly and will encourage them to vocalize any issues or delays in advance.” Usage of daily stand up is highly encouraged in this place

Expecting Software to Solve All Your Project Management Issues. “I’ve seen people throw software at problems all too often, and though projects become enumerated and more visible, the underlying process is still broken, What you end up with in that case is a potentially costly piece of software only serving as a checklist of projects in motion without any thought given to advancing each project/milestone effectively. Choose project management software wisely — something all members of the team will be comfortable using. Then make sure to train users properly and set up a system for tracking projects. Above all, don’t let human capital be “overshadowed by the allure of software solutions’!”

Not creating enough awareness at the management level about agile and scrum:  One of the major issues that I have observed is that your respective management would go ahead and provide relevant training to the development team, create scrum masters and so on …. Have they ever thought of themselves getting a little bit of orientation on the agile, Well if your organization is going to embark on the journey of Agile, it is important that you yourself get acquainted with some terms, terminologies of Agile so that you are atleast at some level playing field when you do some discussions with your Scrum teams. This is one area where in I believe that the management could have done a lot more better than what is happening today, infact at times, I believe this could be the root cause of major issues and problems for which the agile implementation is not happening as needed and required in the organization

Is there a common Agile project management mistake I didn’t include? Please leave a comment letting me know, along with the solution.

By now have you realized who is the bi-cycle tyre? If not then …. Keep thinking …. Still not done, drop me an email.

Are we done as yet?

“Are you done yet?”
The answer to this question may sink your career, your team and your project. If you respond with a “yes,” you may be forced to take on additional work. If you say “no,” you may be branded as someone who can’t get things done.

This innocent question is asked countless times on almost every software project. The way we answer, however, is anything but innocuous. If team members’ answers vary, it can degrade stakeholders’ trust in the project team.

We all have the classic stories of 90% done, but do remember it is not complete.
Establishing an upfront, common understanding of “done” can save teams and businesses countless hours of refactoring, process-thrash, unclear communication, and hidden work.

In this article, I describe a done list, how it adds value, and the value it communicates to stakeholders. Then, I present an exercise that will help you build your own done list and manage it over time

During one of my consulting assignments, I was co-ordinating a user story workshop, the precursor to a kickoff meeting for a large, product development for multiple releases planned for 3 Qtrs. There were roughly 16 stakeholders in the room: engineers, marketing managers, developers, testers, product managers and salespeople. I knew from the beginning that such a diverse group would be a challenge and that I would need to focus the meeting in order to filter out the noise and get the real requirements needed to start the work.

Prior to the meeting, the team (developers and testers) and I had met to create our done list. Though I had the list with me, We chose not to share it at the beginning of the meeting. We did this for two reasons: I wanted to ensure people felt open and unconstrained by a predetermined list and did not want them to get the impression that the done list was up for negotiation.

Two and half hours into the meeting, we had identified approximately 120 stories. This was a huge success; however, people were starting to get hung up on the order in which the stories would be accomplished and how can we be sure of the quality produced. Naturally, the product manager wanted to see monitoring, architecture and other related elements checked out. The marketing people just wanted a release date. The developers and testers wanted to drill into the weeds to figure out what each story meant.

It was at this point that I revealed the done list as identified by the team. The done list covered what it meant to be done with a story, a sprint, a release to our integration environments and, last but not least, our release to production environment (general market)

For a user story, the following was proposed:

• All code developed
• All code unit tested
• All code is checked in mainline server

For a Sprint, the following was proposed:

• Performance testing completed (executed)
• All bugs closed or a work around is identified
• Code Coverage analysis is > 80%
• Class and architecture diagrams are updated

For a Release to Integration, the following was proposed:

• All sprint DOD is completed
• Release notes developed
• Operations guide updated
• Error manual updated
• All test suites as developed are passed
• Installation packages created

For a Release to production, the following was proposed:

• All integration DOD is completed
• Performance tunning done
• Stress testing performed
• Release Notes, Packaging and marketing material is updated

Our stakeholders were shocked and surprised at the data presented. They remarked that they had never seen such detailed level commitment to a quality release before. After seeing the list, the product manager was comfortable with the level of work we were doing to address their needs on each story, sprint and release. Equally (if not more) satisfied were the sales, marketing, and general management stakeholders.
The list helped all the stakeholders visualize the team’s commitment to do the best possible work to meet the needs of the business and its customers. To the team, the done list was a way of life—not a checklist to follow, but a commitment to excellence.

Done criteria helps in establishing expectation of the system and approach the same. The list gives us a way to communicate. When everyone can see what it means for this team to be done with its work, the team no longer hears, “Are you done with this or are you done with that?” Instead they are asked, “Is this story complete? Is the sprint complete? Have you released to your product / release?” And everyone understands what an affirmative answer really means.

Steps required to be define “Definition of Done”

You will need the following items to perform define “DoD”:
1. Your team (Please ensure Scrum Master is included in this meeting), It is the Scrum Master who should take the lead in this meeting
2. Many pads of Post-It™ notes in multiple colors (stickies)
3. Pens / Pencils / Markers
4. Flip charts / White boards
5. If past experience is available , Please ensure it is read and understood by participants before coming to this discussion (this helps to understand what worked and what did not in previous releases and sprints of other projects / products
6. A room that the team can utilize for two to four hours
7. An open mind
8. No disturbances (keep the phones out)
9. Scrum Master should act like a catalyst on this meeting, should not get involved in the discussion
The Done List discussion is constructed of these 4 components:
1. Brain writing Session
2. Affinity Session
3. Discussion and final agreement Session
4. Done List Creation and Publishing
Remember that levels of done come in various forms, the most common being technical and functional. The story and samples presented here illustrate a level of technical doneness

How to run the session:

1. Give high level ideas to the team of what is expected from them in the session
2. Request the team members to write one “DoD” on one sticky note
3. Provide the team about 45 mins to perform this activity, each member to do this activity in his / her own capacity
4. Take 4-5 flip charts and paste them on the wall / white board
5. Create a flipchart for ‘parking lot’
6. Once the allocated time is over … Use the next part of 1.15 Hrs to discuss the item on the sticky notes
7. Use the concept of affinity diagrams to sort and bucketize the data into various segments
8. Label each flipchart as:
a) For a user story
b) For a sprint
c) For integration / other (what ever the step / milestone is called in the organization)
d) For a release
9. In a sequence take each item of the sticky note and discuss the same and have an agreement , which bucket it should be allocated to
10. Should there is a area of ds-agreement have the item posted on the parking lot for later discussion
11. Once all the items are completed as written, ask the team if there is anything else that they would like to add the existing elements (if yes, take the data on a sticky note and have it posted in the relevant bucket, once all the participants agree
12. As a last step discuss the item posted on the parking lot
13. Once all the items are discussed and pasted in relevant categories, take each category and have a discussion, if all the necessary aspects have been covered. If there are dis-agreements, resolve by discussions
14. Once completed have them neatly written down as in separate flip charts (this should be there in the team room) and also in power point (this is for other stakeholders) or one can also take digital pictures of the information as discussed so far and keep them in the share drive / folder

Review of Definition of Done

Remember, a done list is not static. It should be revised as needed (but not too often) and re-published. When used correctly, it provides the team with a common vision on how to achieve the iteration, release and project goals

As anything other element in Agile , the “DoD” should also be under review, a good place to review the “DoD” would be the retrospective ceremony of Sprint, This is a place where the reality of sprint should be discussed and understood. During this meeting, the team should revisit the “DoD” and ensure it is still valid, no additions / deletions are required in the system. If this requires an update, the team should develop the new elements as needed and required and have it discussed and reviewed with all the relevant stakeholders of the project.

One can apply ‘done’ criteria to any activity or a task, all it requires is a little extra thought process to be in place. Impact of ‘done’ criteria would be on estimation of the user story (this is one blind spot in the system)