Definition of Ready – A new thought process in Agile

I’ve seen a lot of projects fail when by all accounts, they shouldn’t have. The reason for this nearly every time, was that the requirements gathering stage of a project was done poorly, or sometimes not at all.  Sometimes this is driven by budget or deadline constraints, and sometimes it’s because the people responsible are just unaware of how to go about gathering requirements in a structured manner, and if you’re have faced one of the above stated problems or know one of those people, then please read on.

Requirements exist to make sure that what you think you are building, is the same as what the client or stakeholder thinks you are building. Requirements serve many purposes, but when you strip them down to their core, requirements exist to make sure that what you think you are building, is the same as what the client or stakeholder thinks you are building.  Because of this, they should be as easy to read and understand as possible, which things like functional specification documents usually aren’t.

User stories are probably the most popular technique to capture product functionality in an agile context. A story contains a name, a brief narrative, and acceptance criteria. It’s comparatively easy to write, decompose, and refine user stories. But writing good stories can be hard and difficult and writing stories which can be used by the development team to further progress and create a potentially shippable product is more tougher.

All of us who follow Agile and related practices and frameworks are aware on the concept of “Definition of Done”, Which is to evaluate and figure out the work as performed the development Team and understand the readiness of the user stories as committed by the team during the iteration / sprint planning.

During one of my interaction with a client team, I had an interesting experience and the idea discussed was, if the Product Owner and the relevant stakeholders evaluate the user stories on some pre-defined criteria’s (read “Definition of Done”), why do the development team do not get adequate rights to evaluate in a similar manner and fashion the correctness and information as provided in the User Stories. It was a valid point from their side, is what I felt, but led to a higher level element of thinking …. on how do we achieve this.

This led to the idea of innovating a new element in Agile World — “Definition of Ready”, something which would and could be utilized by the development teams to evaluate the user stories and reject if it does not meet the required DoR

DoR would work in a similar manner as DoD, but DoR would be the starting point of the system, where DoD would be used and utilized at a later part in the system. There is quite a bit of thought process already available in the market with respect to writing good and useful User Stories, some of them are “DEEP” and “INVEST”.

The DEEP discussed the following elements in the system:

• Detailed Appropriately.    User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that will not be developed for awhile should be described with less detail.
• Estimated. The product backlog is more than a list of all work to be done; it is also a useful planning tool. Because items further down the backlog are not as well understood (yet), the estimates associated with them will be less precise than estimates given items at the top.
• Emergent. A product backlog is not static. It will change over time. As more is learned, user stories on the product backlog will be added, removed, or reprioritized.
• Prioritized. The product backlog should be sorted with the most valuable items at the top and the least valuable at the bottom. By always working in priority order, the team is able to maximize the value of the product or system being developed.

The above are a good starting point, but would require a lot more thought process. One other element that is around in the Agile world for a long time is the concept of INVEST in User stories

• Independent  The user story should be self-contained, in a way that there is no inherent dependency on another user story.
• Negotiable     User stories, up until they are part of a Sprint, can always be changed and rewritten.
• Valuable        A user story must deliver value to the end user.
• Estimable       You must always be able to estimate the size of a user story.
• Small             Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
• Testable         The user story or its related description must provide the necessary information to make test development possible.

Again the above elements are more generic in nature can have a level of difference across team members as to what would be what, the idea is to have quantified elements for DoR and then use them to evaluate the required User Stories to meet the minimum qualification criteria. One cannot be standardizing these ideas, as they would be required to be home grown and adapted to the needs and requirements of the development team (of course in agreement with the Product Owner)

Not everything can be a User Story : Don’t feel obligated to describe every single aspect of the product as a user story. For instance, user interface design ideas are often best captured in form of paper sketches 

Finally thoughts … It is through the process of trying to quantify objectives that we probe more deeply into what’s really important

Management Role in Scrum

ScrumMaster is a management role, but Management has no role in Agile Scrum business …. Interesting.

One should be always asking the question how can Management help a Scrum team. The current understanding in the industry based on my experience is that Scrum was just a tool to shield developers from management, forcing management to interact with developers on their terms.

There are two key things that management can provide: Vision and Organizational Support (i.e. impediment removal, thereby improving productivity). For the starters, Take a leaf from Toyota’s way of working, Management should have “vision and strategy, with enough knowledge to be able to translate that into day-to-day concepts”. Someone capable of driving a common goal and vision across all products and projects.

In Scrum, Management’s role should be that of Change Agent, It is all about bringing an organizational change,  change in the thought process.

When agile is introduced into an organization, a tremendous amount of organizational change must occur to empower and enable agile teams in their pursuit of delivering business value. A ScrumMaster needs to develop keen skills in organizational change and an ability to shepherd an organization through the adoption change curve.

Affecting existing performance management systems, working with peer managers to lean-out business processes, and saying “no” to starting more work are all typical examples of thorny organizational impediments that any ScrumMaster will likely face.

For any Scrum initiative to be successful, one requires the basic change in the thought process, actions from the management side, I realize based on my 24 months of experience that development teams are trained in Scrum Practices, but the Sr. Management of the organization has little or no clue on what are the rules of engagement in a Scrum World, What should be the expectation from the system, They still live in the old traditional style of management.

It is important for us to understand that Management should also be oriented on the concepts of Scrum and adequate expectation management should be performed with them, In absence of the same, the entire structure would collapse and there would be no ROI available

During one of my assignments, I heard a Sr. Manager making an interesting statement I quote “We want to follow and adopt the Scrum Practice, because all our competitors are doing it and we do not want to left out of the race”, This set the bell ringing in my mind, are we doing Agile Scrum, because others are doing it? Do we really have a need for doing Scrum, Does it warrant our nature of business? What is our expectation from the system?

Many a questions, but no real answers coming out.

One needs to understand the basic principle in Scrum Team, that they are supposed to be self-organizing and self-managing, In such a case, many of the “classic” management tasks are no longer important or even appropriate.

Blanchard & Hersey have created theories where in they realized that there were different management styles appropriate for different situations.  They created the Situational Leadership model to map effective leadership styles to different situations.  The most effective leadership style for a group of people who are “Willing to Do the Job + Have Ability to do the Job” , This is the group that would be ideally suited for the Agile Scrum Business, Set up the process and allow them the freedom to do the job, let them run the system, wait on the side lines and guide when required, Doesn’t this  Sounds like an Scrum World

Going from involvement to commitment is a big step, one that will not occur naturally. For a firm to have Committed employees, the Management must be committed first, do that it must undertake the following:

• Have Clear Goals. The purpose of a company must be worthwhile and serve a greater purpose than just making a profit. People who believe in the company goals will be committed to working hard to achieve the desired purpose of the organization.

• Empower People. Employees will only be committed when they feel they have some control over their work, having a voice in what is done, and are able to make decisions about how they perform their jobs. What empowerment does mean is that within the guidelines of the organization’s goals and procedures, a person has some control over how they go about doing their part to achieve these goals.

• Show the required commitment to employees. Employees will not be committed to a company, unless they feel the company is also committed to them. A company demonstrates its commitment to its employees by providing compensation packages (including perks), treating employees with respect, trusting its workers and acting with integrity.

• Share the rewards. If employees are to go above and beyond on a consistent basis they need to believe that they will be rewarded for their commitment. Committed employees produce extraordinary results, but their commitment will soon fade if the fruits of their efforts are not shared.

This level of employee commitment will only occur when the firm displays a commitment to its employees by implementing the factors mentioned above. This type of orientation creates a win-win situation, where consumer needs are met, employees feel good about their contributions and the firm earns a profit.

This for me would be the role of the Management in a Scrum Project

Is there any failure concept in Agile?

Today, as I was in a training, I was asked a question, What does failure in Agile mean? How do measure a failure in Agile? It was deep rooted question for me and made me to think that what is a failure, Never consider this element in context of Agile, where as in traditional projects that we execute, if the project does not meet the requirements of OTOBOS (On Time, On Budget and On Scope), we believe and tend to label the project as a failure. Why is the same concept not applied to Agile.

Why do we keep on highlighting that to implement Agile and its related frameworks like Scrum or XP, it would take any team about 3-4 good iterations (or should I say Sprints in the lingo of Scrum), why are we ready to provide this kind of get away to Agile implemented projects and not to the traditional approaches

The basic fundamental of Agile is to Inspect and Adapt at regular intervals (which could mean even daily), which means we are entitled to make mistakes, learn from them and re-implement the same in a new incarnation and so we say, we learn from our mistakes.

What happens when the same issue or the mistake is repeated again, does this mean we have not learned our lessons, we have not performed the concept of Inspect and Adapt adequately?

So does Agile embraces the idea of failure.  Are we saying that failures are “good” and that we should not worry about our results, time, cost, effort, resources and other related elements.

Well it may not be the case, as  Agile implementation mindset, however, looks and understands  failure differently. In Agile individuals are not  are not failures, but our experiments might not give the results we desired or expected.

As Agilists we love to talk about our successes but its much harder to talk about failure. We do have a lot if information available on how agile was successful and how and how much ROI was generated, But one has never questioned, the data regarding the failures of the agile processes

I have also observed in last few assignments of mine, that the Top Management of the organization is still working the old traditional approaches, where as they expect the team to do Agile?

Failure should be considered as a part of our learning process, but in the current world that we live, we do not have room for making failures, the world is moving faster than one could imagine and the fear of getting left behind or missing the bus, does not allow us to look at failures in a positive environment. The patience of management is running low and reducing on a daily basis (the account balance of the patience is getting depleted on a regular basis)

In the Agile world we regard failure differently. The Mantra to be used in Agile should be:

1. Fail Often, Fail Early
2. Use failure as a Feedback loop
3. Use Failure as an expansion of your knowledge (something that we did not know is now known)
4. Failure is inevitable and should be considered as a part of our learning process

Does this mean, we have got the license to make mistakes, well not really, it is OK to have failures, as it allows you to learn from it, having 365 new failures each year, allows you to improve 365 times, but repeating the same mistake again, should be consider as a CRIME , even in the Agile world

With tons of dollars in sunk cost every day, and a high rate of project failure,  shouldn’t we be formally logging and analyzing failures?” , At times documentation is performed, but the in reality the documentation is more for academic reasons, rather than learning reasons …

Finally, I would like to remind, a note that I was reading at some location:

“When you goof up and make huge mistakes and suddenly you start to smile, it indicates that you have already thought of someone whom you can blame it on”

Hello world from Ajay Kabra

Hi All

This is Ajay Kabra, I have started and attempting to blog using this blogging site.

The objectives or my blogs would be in and around Agile , Scrum and their implementation and experiences

Do drop in your feedback from time to time to help and encourage me to improve.

Cheers

Ajay Kabra