There is a misconception that agile is just about processes, and primarily for software development. This is a narrow view and as long as we see it that way, we deprive ourselves of the real benefits of Agile.
Agile is much more than that. It is an approach and a way of working (Agile Method). It is a way of thinking and a state of mind (Agile Mind). In short,
Agile = Agile Method + Agile Mind
Even in software development, it is not limited to a few processes but can be applied to all processes. In fact once the Agile is used fully for software development, it will start being used in all our walks of life. After all, it is one life and can’t be compartmentalized.
In next few weeks, let us explore this line of thought in detail.
Introduction: It is understandable but unfortunate that the very mention of the term software engineering evokes such a strong reaction in the agile community. It is understandable because of the burden of the past when good intentions turned into bad practices and unfortunate because in the process we tend to throw the baby out with the bath water.
Agility: The essence of agility is transparency inspection and adaptation. If we look at the Agile Manifesto, we see that the earlier focus on terms like “processes and tools, comprehensive documentation, contract negotiation and following a plan” had frozen the continuity. This I like to call as Agile -1.
Change over continuity: The terms on the left of the value statements in the Manifesto like “Individuals and interactions, working software, customer collaboration and responding to change” emphasized the importance of a human observer who would inspect the content with the context and adapt the approach to align them. The intention was very good but the potential energy of the earlier imbalance was released and swung the pendulum on the other side. This was a phase of Agile 1.
Agile is now mature: By the end of the first decade, agile has become a mainstream methodology and matured enough to be able to give equal importance to both the sides of the equation and provide a way for the practitioners to adapt their practices to the changing context. It has thawed the frozen continuity and can help us to consider logically the benefits of managing continuity well while also responding to change. So we are entering a phase of Agile 0. At first sight, 0 appears empty and hence meaningless. But being empty also frees it from the burden of the past, and opens up limitless possibilities.
Continuity with change: Let us look more closely at continuity and change. When we start developing a new software system, it is all about change. As it grows, elements of software maintenance start entering the picture. Over a period of time, the proportion changes and ultimately we reach a stage when the bulk of the work is to maintain the existing system with little new functionality added from time to time. Managing continuity becomes more important than managing the change. So at different stages, the mix of continuity and change differs and our practices also need to change accordingly.
Systems perspective: It would help to look at this from the systems perspective. The internal state of the system is represented by the state of its content. Similarly, the external state of the system is represented by the current state of its context. Whenever there is a misalignment between the internal state and the external state of the system, it results in creative tension. This tension can be reduced by suitably changing the content or the context or both. But before this happens we need to inspect the current states of the system, which in turn needs access to the right information in time; in other words transparency.
Real life example: Let us understand this with an example. A person brought up in a traditional joint family marries and starts a nuclear family in a big city. He still carries with him the values of a joint family but has to deal with the expectations of living in a big city. He needs to objectively see this and change either his values or manage expectations of others. How he decides to adapt is up to him but unless he is aware of the misalignment, he may end up bring an emotional wreck.
System states: The internal state of a system is the assumptions beliefs and the values it holds along with the current set of practices being used repeatedly. The external state is the interface projected to others and expectations of others from the system, along with the repetitive interactions. In the above example, the tension is generated by the misalignment between what he is and how he wants to appear to outsiders.
System stability: Apart from the system states, it is important to understand system stability. A stable system has minimum hindrance to the free flow of system energy, or synergy for short. Internal stability comes from well-coordinated actions, while external stability is about well-coordinated interactions with other systems. An internally stable system may or may not be externally stable, and vice versa.
From the software system perspective when we start making any changes to it, the internal system becomes unstable till it goes to the next stable state. The iterative development brought in small jumps from one stable state to another as compared to waterfall. This is also expressed as “potentially shippable product” in Scrum. The external stability is governed by the interface exposed and the changing expectations of others from the system. So during iteration as long as the earlier stable version exposed outside remains in sync with the expectations, there is external stability.
Adaptation options: The concept of internal & external stability is important for deciding between continuity and change while adapting to the new reality, as it becomes visible after inspection. During inspection we observe the internal and external states of the system. If they are misaligned, it may call for change. However, the change may be required to the internal state or external state or both.
If the system is internally unstable, we need changes to make it stable. But we have a choice to either take it back to the earlier stable state or forward to a new stable state. This in turn depends on how it would impact external stability.
If the system is internally stable but externally unstable, we have to decide whether to make external changes or internal ones and accordingly plan our actions. It is not always prudent to start changing the software as soon as new requirements come, without considering the resultant states. Sometimes it may be necessary to delay or deny the requested changes in the overall interest.
So far we have seen responses which were reactive. What if the system is currently stable both internally and externally? Should we let it be or proactively anticipate changes in future? We may decide to either continue the status-quo or to go for change, but we will reach the next level of stability much faster.
Inspection: With this background, let us examine what is involved in inspection. Traditionally, inspection means an action planned to know the current state and more often than not involves measurement, which requires collecting data and analyzing it. There is another part of inspection which is normally neglected. It is about observing the instances of exceptional behavior, capturing them and understanding the hidden cause or causes. Such exceptions have a tremendous potential to give us a glimpse into the emerging reality before it starts showing up through measurement.
Transparency: Reliable inspection depends on transparency. Transparency is the ability to see the reality without any obstruction or distortion. Normally, the persons who see it may not be persons who need to act on it. In case of inspection using measurement, it means that the persons who have access to the raw data do not hide it and those who analyze do not distort it. In case of observation, since the exceptions are not controlled by us, they need to be shared by those observing it to those who can analyze and ultimately to those who can act on it. Since this can’t be defined as a process, it needs to become part of the culture as an informal communication, almost bordering on gossip.
What’s in it for me? How does all this help us? Once we become aware of our attachment to one way of thinking and the knee jerk reaction against the other, we can start exploring the fundamentals at the human systems level and apply them to software development to see them in this new light. It will provide us pointers to examine our current practices and suitably modify them as we see them working. We can also benefit in other areas of our life beyond software.
Explore and share with others: Paraphrasing from the Agile Manifesto Let us together “Uncover better ways of managing our practices, by doing it and helping others do it”. When we are able to do it across the software community and get it into the collective consciousness, we would reach the stage of a perfect balance or in other words Agile 0.0
As per the news item posted by Semat http://www.semat.org on 28th Feb 2012, OMG had put out an RFP for a proposed standard “Foundation for the Agile Creation and Enactment of Software Engineering Methods (FACESEM) RFP (OMG Document ad/2011-06-26)”. Semat working group has submitted a proposal entitled “Essence – Kernel and Language for Software Engineering” on 20th Feb 2012. This is an interesting development and I would like to share my thoughts on those aspects which I believe would be of interest to the software practitioners, including those who are familiar with agile ways of doing things.
It is interesting to note that the RFP asks for an “AGILE” foundation for creation and enactment of software engineering methods. This is in sharp contrast to the current practice of methods being created once by process experts to be used repeatedly thereafter by the practitioners. The term “process”, which is so widely used currently, is also conspicuous by its absence from the defined terms in the proposal. Instead it works with practice which is defined as “repeatable approach to doing something with a specific purpose in mind” and method which is “composition of practices forming a description of how an endeavor is performed”.
The direction software engineering is likely to take in future is indicated by the key differentiators mentioned in the proposal,
- Finding the essence of software engineering so that it can be applied to and reused across different application domains and software systems of differing complexity
- Working with methods in an agile way that are as close to practitioners’ practice as possible, so that they can evolve the methods and adapt them to their particular context
- Focusing on what helps the least experienced developers over what helps the more experienced developers
- Supporting practitioners over process engineers
- Emphasizing intuitive and concrete graphical syntax over formal semantics
- Focusing on method use over method definition
In short, the proposals by Semat and others leading to a standard can be expected to benefit the practitioners, giving them a greater say in deciding how they go about developing software, or to use the term from the proposal, their “Way of working”. The universal kernel and a common language would also support the concept “think globally act locally” and provide a common foundation to tackle variety of contexts and situations in a consistent way.
When I was discussing this topic with my colleagues, I was surprised to see how quickly they concluded that it is only related to agile software development whereas it is applicable to all kinds of software development, agile or otherwise. It is actually more about how we decide to develop software rather than how we develop software.
This reminded me of Mike Cohn’s Blog “Succeeding with Agile” http://blog.mountaingoatsoftware.com/reflections-on-the-10-years-since-the-agile-manifesto which I had read some time back. As he says, we stopped talking about objects a while ago and similarly we will stop talking about agile. Rather than “agile software development” it is just “software development.” Rather than “agile project management” it is just “project management”— Of course it’s agile.
But for this to happen, I feel we will need a greater understanding of the opposing forces at play before we can optimally balance them to suit specific situations. Few examples of such universal opposing forces applicable to all human systems are,
- Defined versus empirical
- Transparency verses privacy
- Inspection verses automation
- Planning versus preparing
- Compulsion verses discretion
- Early verses late binding (of decisions to actions)
- (Internal) cohesion versus (external) coupling
Does the above thought process make sense? What are your views on this?
Charles Goodhart, a former advisor to the Bank of England and emeritus professor at the London School of Economics had proposed a law in 1975 that “once a social or economic indicator is made a target for the purpose of guiding policy, then it will lose the information content that originally made it useful”. It was later simplified and made more generic by Professor Marilyn Strathern as “When a measure becomes a target, it ceases to be a good measure”.
Most of the examples published about its applicability are from communist countries. I was looking for something closer to our domain. Last week I saw a good article by Lee Copeland in the latest issue of “Better software magazine” which I am sure may interest you. He puts it very nicely as “Connecting rewards and punishments to specific goals can negatively impact a metric’s usefulness”. Here are some of the relevant conclusions and examples from this article.
Management chooses a metric in an attempt to understand the behavior of a system or process. Later, this same metric becomes a goal (“Attain this value or else”). When this occurs, the “or else” part motivates people to change their behavior to achieve the goal. Some examples,
When LOC/day becomes a goal, developers may be enticed to write more lines of less efficient code.
One of the indicators of the quality of system design is the subclass: superclass ratio—sometimes called the specialization ratio. At one company, not only was the specialization ratio measured, but a goal was set—the specialization ratio had to be 3 or above. Designs not meeting that goal were sent back for rework. Developers, not liking rework, simply added cleverly disguised empty classes until the ratio was met.
In other cases, rewarding testers for the number of test cases resulted in many poorly written test cases; rewarding testers for the number of bugs they found resulted in a high number of unimportant or duplicate bugs reported; and penalizing testers for bugs rejected by the development staff resulted in important bugs going unreported.
And he concludes, “Goodhart’s Law reminds us that connecting rewards and punishments to the achievement of specific goals can create unintended consequences. Some will strive to reach those numbers without concern for anything else. If the person being measured is affected by the outcome, she is likely either to lie, thus subverting the usefulness of the measurement, or to focus on what is being measured without regard for the consequences”.
What is the solution? Some of the options found in other more generic articles are,
Specify the information required, but don’t disclose how it will be interpreted (To me this seems to be fraught with trust issues)
Depend more on human discretion (This gives the flexibility but may not scale)
Balanced scorecards (Useful if the interpretation considers the balancing effect, but would have same problems if each measure is taken by itself and judged)
Theory of constraints – which is about focusing on bottlenecks (This has the benefit that once a bottleneck is taken care, it exposes other bottlenecks and the measures could now be moved to the new bottlenecks)
Your views and inputs are valuable; please share.
Recently in July 2011 Ken Schwaber and
Jeff Sutherland have published the Scrum update and a Scrum guide. The Scrum
update cites an example of the game of Chess and distinguishes between rules of
the game which are applicable to all players, from strategies which can be
different for different players. The accompanying Scrum guide covers the rules,
leaving the numerous strategies for success to other available resources. It
would therefore be worthwhile for a team practicing Scrum to see the rules from
the Scrum guide and identify areas where there are mismatches so that they can
make necessary changes to their practices. Here are a few examples of different
types from the documents. I have quoted them verbatim to ensure authenticity.
I would like to mention here some rules
because of their importance. This is important for teams moving to Scrum for
the first time because it is easy to fall back to old habits. However,
sometimes even the teams already practicing Scrum need to remember them.
For the Product Owner to
succeed, No one is allowed to tell the Development Team to work from a
different set of priorities, and the Development Team isn’t allowed to act on
what anyone else says.
The Scrum Master is a
servant-leader for the Scrum Team.
In the Sprint planning meeting,
the plan is created by the collaborative work of the entire Scrum Team.
The number of items selected
from the Product Backlog for the Sprint is solely up to the Development Team.
Only the Development Team can assess what it can accomplish over the upcoming
The work remaining and date are
the only variables of interest. The Development Team tracks this total work
remaining at least for every Daily Scrum.
As Scrum Teams mature, it is
expected that their Definition of “Done” will expand to include more stringent
criteria for higher quality.
Here are some examples of rules which
are different from what is commonly understood.
Scrum recognizes no titles for
Development Team members other than Developer, regardless of the work being
performed by the person; there are no exceptions to this rule. Development
Teams do not contain sub-teams dedicated to particular domains like testing or
The Scrum Master ensures that
the Development Team has the meeting, but the Development Team is responsible
for conducting the Daily Scrum.
After the Development Team
forecasts the Product Backlog items it will deliver in the Sprint, the Scrum
Team crafts a Sprint Goal.
The Daily Scrum is not a status
meeting, and is for the people transforming the Product Backlog items into an
Every day, the Development Team
should be able to explain to the Product Owner and Scrum Master how it intends
to work together as a self-organizing team to accomplish the goal and create
the anticipated increment in the remainder of the Sprint.
Each Increment is additive to
all prior Increments and thoroughly tested, ensuring that all Increments work
together. A Sprint Review Meeting is an informal meeting, and the presentation
of the Increment is intended to elicit feedback and foster collaboration.
The Sprint Retrospective occurs
after the Sprint Review and prior to the next Sprint Planning Meeting.
There are also cases of what was once
considered as rules are no more so,
Development Teams do not commit
to completing the work planned during a Sprint Planning Meeting. The
Development Team creates a forecast of work it believes will be done, but that
forecast will change as more becomes known throughout the Sprint. The Sprint
Goal gives the Development Team some flexibility regarding the functionality
implemented within the Sprint.
Scrum does not mandate a
burn-down chart to monitor progress. Scrum requires only that remaining work
for a Sprint is summed and known on a daily basis.
Release Planning is a valuable
thing to do when using Scrum, but isn’t required by Scrum itself.
The Sprint Backlog is the
Product Backlog items selected for the Sprint, plus a plan for delivering them.
There is no longer a required concept of “Sprint Backlog items”.
The erstwhile project managers from the
non-Scrum projects feel loss of power & authority when they move to Scrum
as they typically move over to a role of a Scrum master. The Scrum guide
provides an elaborate list of ways in which a Scrum master can serve the product
owner, development team and the organization. Though the guide specifically
mentions that the Scrum master is responsible for ensuring that the Scrum team
adheres to the rules, I feel he can also serve the team by coaching them on
appropriate strategies to handle different situations.
Those who value their contribution and
understand the importance of being a Scrum master will play the role with full
zeal. On the other hand, those lost in the nostalgia of old glory & power
would neither be here nor there and would soon be ineffective. This may be a
critical decision for them whether they want to continue with a project moving
from non-Scrum to Scrum or move over to another non-Scrum project.
I also feel that even for non-Scrum
projects, the practice of separation between rules & strategies and clearly
identifying & documenting the rules can be quite useful. The team leader
can play an effective role in this and make sure that the rules are followed
and the team members are adequately coached in applying right strategies in a
Your views and inputs are valuable;
Scrum is developed and sustained by Ken Schwaber and Jeff Sutherland. Recently in July 2011 they have published on Scrum.org latest version of the Scrum guide, which defines the Rules of the Game. While I was reading it, one statement caught my attention.
“Scrum is lightweight, simple to understand (but) extremely difficult to master”. It is quite a bold statement and yet captures the reality quite accurately. I was interested to know why they feel so, but they have not elaborated it any further in this guide. Still it is quite important for us to know because if we try to figure out why it is difficult to master, it will help us to get over the difficulties and derive maximum benefit from implementing Scrum in our projects.
As I read the guide carefully, I found some pointers which we can collectively use to gain a better understanding of the issues involved. I am quoting below relevant portions from the guide, not necessarily in the order in which they appear, but grouped suitably to help interpret them better.
Let’s start from the top,
“The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner. No one is allowed to tell the Development Team to work from a different set of priorities, and the Development Team isn’t allowed to act on what anyone else says”.
This is easier said than done. Those stakeholders (chickens in Scrum vocabulary) who are powerful / influential / vocal / trouble-maker are used to having their way and would strongly resist / derail any attempts to take away their freedom. The top management needs to put its foot down and make clear to all concerned that the above rules related to product owner’s authority & responsibility are in the interest of the organization and hence must be strictly followed. Once everybody accepts and starts practicing, it will become part of the organization’s culture.
The team also needs to have a major mindset change,
“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint”.
This is challenging both for the team members and the team leaders. The team members are so used to the planning & monitoring work being done by the team leaders that they feel it an additional overhead where they are expected to do it themselves. They also feel threatened as the responsibility for any failures would be now on them. They try to find ways to sabotage the new way of working by quietly continuing the old ways.
On the other hand, the team leaders suddenly feel the loss of power and are also interested in continuing with the status quo. This combination makes it very tough for the Scrum master to protect and support the Scrum practices and it takes a very persuasive and determined Scrum master to pass the initial phase successfully till the team members have tasted the new freedom and understand the benefits to them. In this phase the Scrum master also needs understanding & support from the management.
For the organizations who believe in process-driven way of working, the empirical nature of Scrum is difficult to digest,
“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk”.
This tentative approach is unsettling for those who strongly believe in setting the standards and controlling variations. They use data to control & minimize variations; whereas Scrum uses data to learn from experience and adapt future course of action. For example, traditionally the data about time spent on doing different tasks is collected and analyzed to control effort variance; whereas “Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date (of completion) are the only variables of interest”.
At first glance it may appear that Scrum is neglecting useful data but it makes sense when we see it in relation to other scrum concepts & practices like self-organizing teams, transparency and learning from experience during retrospectives. The team members are encouraged to realistically indicate on a daily basis the remaining time for a task, without fear of being questioned even if it higher than originally estimated and making the actual status of the project known to all concerned. The visibility and transparency coupled with fixed date & scope of completion set in motion the corrective actions that are far more powerful than analysis of effort variance much later. The sprint-end retrospective gives an opportunity to the team to learn from such cases of poor estimation.
Lastly, there is a misconception that following an agile approach means you are free to use some parts of Scrum which suits the team and conveniently avoid the tough discipline in the name of tailoring; whereas Scrum says “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices”.
To master Scrum, all those involved directly or indirectly have to understand the implications mentioned above and accept short term inconveniences to get the long term benefits. Scrum can be highly successful when that happens. Otherwise if it is adopted because it is the new fashion, it will be worse that what it was before Scrum.
Each of the Scrum practices is simple and easy to understand. The real challenge is to grasp them in totality. It requires synthesis, not analysis. It requires a mind which is open to explore experiment, learn as well as unlearn. There comes an ‘aha’ moment when suddenly everything falls in place; that is the beginning of mastering Scrum.
From one stable state to another
Scrum strongly recommends creating a “potentially shippable product” at the end of each sprint. In my Scrum training & coaching experience, I have come across many questions & doubts about its practicality. It is often argued that when we are not going to put the next increment in production, does it make sense to aim for it. After giving this due thought, I have come to the conclusion that the answer can be found at the systems level.
What Scrum is trying to ensure is that the software system moves from a stable state at the beginning of a sprint to another stable state at the end of the sprint. Anything that is started but not finished is a potential threat to the system stability. Hence it advocates breaking more complex product backlog items into smaller user stories so that they can be started and finished in one sprint.
This is a good approach but may not always be practically possible in each and every case. There are a number of interrelated activities and simple cause-effect relationship may not give us a clue to the impact of incompletion of a given factor on the overall system. It is better to be aware of such incompletions and raise them during the daily standup meetings. It also helps to discuss major incompletions and their effect on the system during the sprint-end retrospective meeting. Both these actions will help increase the sensitivity of the team members towards the risk involved.
A common problem faced by the teams relates to sequencing of development and testing. Normally, testing only follows development. However, practices like test driven development (TDD) and behavior driven development (BDD) where failing tests precede coding and amount of code written is kept to the minimum to pass the failing tests. This approach avoids the temptation to cover lot of functionality in one go and the resultant risks of introducing additional bugs. Another practice strongly favored by agile is one of refactoring. Here again, need based separation of concerns helps in doing it in small chunks. Lastly, it helps to have a much better understanding, collaboration and shorter iterations of coding & testing.
There is an important concept of technical debt in Scrum, which simply means “The difference between what was delivered and what should have been delivered”. Whatever is left out in one sprint, generally due to pressures of completing the sprint on time, results in cutting corners on quality. These left overs come back to haunt later, quite often with far more serious consequences. When applied at systems level, a systems debt would cover not only the gap in delivery but also the other aspects like readiness of the team to tackle the demand & challenges of the work involved, absence of good practices and so on. The team needs to consider, plan & work on all such areas.
Though most of these concepts have been explicitly covered in Scrum, there is no reason why the software teams not following Scrum cannot apply some of these in their work. Actually, a team involved in any kind of work and not just software development can benefit from using just two concepts; keeping incompletions to the minimum and being more sensitive to the importance of system stability. Any work makes a system temporarily unstable. It is therefore important to identify future events where systems stability is externally important and work towards achieving it. It is important for the team to observe, discuss and learn from instances that lead to system instability and make this an enjoyable activity.
I would really appreciate any thoughts / experiences from you that either support or challenge what is said above.
Good practices help us to make a steady progress while at the same reducing risks for the future. Few weeks back, we saw one such practice used by Scrum teams, namely daily standup meetings. We also saw that once we understand the opportunities & challenges involved in such good practices, we can fruitfully apply them to not just software developments teams using other than Scrum, they can be used by teams in any other domains as well. One such practice we will see today is retrospective meeting.
As per Scrum, retrospective meeting is an essential practice to be conducted at the end of every sprint (that is iteration). Basically three things are done; what went well, what did not and what do we change for future. Rest of the mechanics of conducting retrospective meetings is well documented and readily available. I would rather focus on the aspects that are not so readily known but can benefit the individuals & the teams immensely. I hope this will generate enough sharing of mutual experiences.
Most important thing to take care is creating the right culture within the team. Some team members are likely to be antagonistic towards each other; there may be intense competition amongst others; they may have different and conflicting perspectives. All this is natural and to be expected. However, for the retrospective meetings to be successful it is very important to keep them aside and focus on what can be learnt from the sprint just completed. There must be frank discussions while at the same time maintaining a positive atmosphere throughout. It is not easy but few things if taken care greatly help. It is important to introduce in the first sprint and reinforced in subsequent sprints. It helps to have an experienced coach manage few initial meetings after which the scrum master can take care of it. For first few sprints, it helps to spend more time on “what went well” rather than “what did not”. Once the right culture is there, we can spend most of the time on improvement areas.
Good culture created and nourished during retrospective meetings helps other practices of Scrum as well. It helps during planning, during daily standup meetings as well as to work as a self-organizing team. This culture of being frank & positive is absolutely critical for success of Scrum.
Daily standup meetings and the retrospective meetings can be mutually supportive. Whatever comes out in the daily standup meetings of a sprint and requires more detailed discussion by the team should be captured and taken up during the retrospective meeting at the end of that sprint. For example, risks identified / unplanned tasks done categorized by person and by nature of reason for not being able to plan earlier / tasks with wide variations between planned hours and actual hours spent, and so.
These are easy to identify and capture. More difficult but very useful are the cases of ongoing tensions and conflicts between team members can be seen & felt by the scrum master and taken up during retrospective meeting. It also helps to highlight & appreciate cases of out of the way help provided by members to each other.
Last but not the least, whatever is decided to be changed for future must be converted into action items with owners & deadlines and effectively tracked till completion. Otherwise, the benefit of identifying such improvement areas will be largely lost.
Your views and experiences are very valuable; please share them.
Daily standup meeting
As a child, I had read a quotation from one of the famous Marathi saints which made a deep impression on me. It was “ekmeka sahayya karu; avaghe dharu supanth” which would loosely translate in English as “Let us help & support each other; let us join this noble movement”. Since then it has been one of the guiding values of my life.
I find Scrum is one such noble movement; it Scrum has a similar underlying philosophy. It strongly encourages sharing amongst team members; whether during sprint planning meeting, during daily standup meeting or during retrospection of successes & learning at the end of each sprint. The task board, burn down chart and even the planning poker are all about sharing and helping each other. Scrum has many good practices which help team members to support each other. Together they produce great synergy. However, even on its own each practice has its value and can be used by teams not following Scrum.
One such practice is a daily team meeting where everybody stands up in a circle for 15 minutes and shares in a round robin fashion with each other what each person has done since the previous meeting, what he plans to do till next meeting and what if anything is holding him up. If taken as a ritual, it loses its real effectiveness. Of course, even as a ritual it helps to let everybody know the progress, status and problems. However, the same time can be used innovatively to do lot more. I would like to share a few things I have encouraged teams that I coach to do and would look forward to hear about your experiences.
Apart from sharing the impediments which already exist, teams can start sharing risks they see going forward. This helps take preemptive actions proactively. It helps to realistically estimate the remaining hours which immediately reflects in the burn down chart and helps draw everybody’s attention. For this purpose, slightly tweaking the practice of updating the remaining hours and burn down chart before rather than after the meeting really helps.
Team members can share if they had to carry out any unexpected task the previous day or need to do it the next day. On one hand, it helps to progressively improve the accuracy of estimating available hours for sprint planning. On the other, if it is happening so frequently as to compromise team’s ability to honor its commitments, it starts creating a back pressure on sales & customers; which may be resisted initially but is good in the long run.
Team members can start appreciating and applauding anything noteworthy done by a member. This instant, specific and positive feedback has a great motivating effect.
Team members can mention where they failed and convert into an opportunity for improvement. When we consider them as failures there is a defensive reaction and normal tendency is to hide it if possible and even if it comes in the open to start finding excuses. The whole atmosphere changes when everybody in the team talks of opportunities for improvement. The effect must be seen to be believed.
The standup also provides an opportunity to identify and record unresolved problems. Normally, when we don’t have a solution to a problem we tend to lose its track. Capturing such cases when they are fresh in our mind and periodically reviewing them in dedicated meetings, may be once a week or a fortnight, helps to keep them in our attention and chances of doing something about it go up.
These are some of the additional activities which further enhance effectiveness of a great practice. Initially, it might take slightly more time than the prescribed 15 minutes. However, a bit more time gives rich dividends. Further, if the team is really keen to honor the time-box suggested by Scrum, they can focus on making their communication even crisper by eliminating everything non-essential or inappropriate for the standup meeting.
I am keen to know your experiences in scrum teams and even more interested to know about how far it helps the non-scrum teams.
It is said that Scrum does not create any new problems; it just brings to surface existing problems faster. One such problem is of developers not being fully aware of what exactly the end user wants & needs. Difference between wants & needs is what the customer explicitly asks for and what is implicitly expected by the user. Of course they get the detailed requirement documents but many important aspects may get missed out as the user wants / needs pass through the customer -> business analyst -> systems analyst -> developer.
Scrum insists on fully completing (including testing) the incremental functionality taken up in a sprint, else it is treated as not done and needs to be taken up afresh in one of the subsequent sprints based on overall priority. Non-scrum projects do not do so. As a result, testers may look at the requirements when developers do the same or even later based on when they plan to test it. As a result the developers typically base their development work on the requirements documents alone and not on test plans / test cases. In many projects, testers do not even have direct access to the business analysts and quite often try to understand the requirements from the developers. This may work in non-scrum projects because there is no insistence on creating a potentially shippable product at the end of each iteration. What is developed in one iteration could be tested in the next iteration or even later.
When such projects move to Scrum, they tend to carry the existing way of working. Very soon, the problem starts surfacing. Developers continue to develop till the last day of sprint and the testers have no time to test what is developed towards the end. The rush job of testing to somehow complete before end of the sprint may leave out some of the important aspects. On the other hand, testers could be under-loaded during the initial days of the sprint because they would have already finished testing for the previous sprint and are now waiting for developers to give something to test. Such a situation starts creating disillusionment about Scrum and team starts resisting the Scrum’s tenet of no change either in due date or deliverable. The team also starts putting pressure to allow testing in next sprint what is developed in later part of the current sprint. If the management gives in and allows, it loses the great benefit of getting early feedback which comes from producing a potentially shippable product and demonstrating the next working increment during the sprint review meeting at the end of the sprint.
This is where the real contribution from the tester comes in. He should be provided direct access to those who interact with the users. He should acquire enough domain knowledge to be able to anticipate the real needs of the users. Equipped with these, he can help create more effective user stories and discuss them with the person managing the requirements creation. He can also start preparing test cases for sprints / iterations coming in future which would be available to the developers along with the requirements.
This approach helps to build a closer interaction of testers on one hand with the business analysts & domain experts and on the other with developers thus acting as an effective bridge between them. It enriches the role of the testers. It also helps to take care of the problems mentioned earlier and risks to successful Scrum implementation in a project.
I would really appreciate any thoughts / experiences from you that either support or challenge what is said above.