Attributes of a true Scrum Master

As per Tao Te Ching

The worst leader is who people despise, a good leader is who people worship. A great leader is he who makes people say "we overselves did it"

If you really look at the responsibilities of a true Scrum Master, he is supposed to be a great leader. One of the key responsibilities of a Scrum Master is to create a Self organizing team, where team is empowered to make decisions, lead the project towards the goal.
* A true Scrum Master(SM) won't spend time micro managing activities of the team and instead, he/she would be working towards creating a space for the team to express themselves.
* SM steps out observing the team, coaching them to move in the right direction. This process of empowerment ultimately makes the team feel possessive about the project and creates an image that "they" did everything.
* A true Scrum Master would stay as an angel not in the view of the team, but keeping a watchful eye on every movement of the team.

So, going back to the quote from Tao Te Ching, the Scrum Masters should not consider themselves as "transformed project managers" but work towards becoming great leaders, satisfying the true meaning of "Scrum Master".

Even though no body is born as a leader, I firmly beleive that some of the leadership skills could be developed by observing other leaders.

Agile world in the Top 20 Blogs

Agile Daily has rated my blog Agile blog in the top 20 list as the most recommended blogs on Agile development.


Here is what they say:
Sorted by Fastest Gain in SocialRank. These blogs had the biggest increase in attention today.

1. Geek Noise
2. ASP.Net
3. James Shore
4. Agile Advice
5. Agile Game Development
6. Jason Yip - Blog
7. George Dinwiddie - Blog
8. Agile .NET CT
9. Agile Programmer
10. Agile Israel
11. Agile Software Process Improvement
12. Me.Andering
13. Diana Larsen - Blog
14. Jeff Sutherland - Blog
15. Agile Artisans
16. Agile Blog
17. TargetProcess
18. Agile Project Planning
19. Better Ways of Developing Software
20. Agile Software Development blogs

Accountability and Productivity

I have been reading one of my favorite books Slack, and in one of the chapters on schedules, Tom brings up a good point about accountability and productivity. He mentions that

When a schedule is not met, those inclined to pass out blame are quick to
point at the lowest-level workers; they reason that performance is the domain
entirely of those who perform the work. They ask plaintively, "why can't these
guys ever meet their schedules" ? the answer that the schedule might have been
wrong in the first place only befuddles them.

He continues to say

There is such a thing as a bad schedule. A bad schedule is one that sets a date that is subsequently missed. .... If the date is missed, the schedule was wrong. ... The purpose of schedule was planning, not goal-setting. Work that is not performed according to a plan invalidates the plan.

My blog feeds are available through ASCI

Agile world blog's posts can be viewed through Agile Software Community of India(ASCI)'s website.

Reducing the stress during software development

We keep seeing the stressed out software development team and the customers, blaming and pointing fingers at each other day in and day out. There are several reasons which causes germination of stress in the team. Some reasons include, poor top leadership, unskilled team, unsupportive customer and poor project planning to name a few.

In this post I am going to share some of my thoughts on reducing the stress by creating a proper project plan and estimation by keeping the forces of nature in mind.

Project plans are always good but it should be flexible enough to accommodate changes, considering the forces of nature in mind. The project dates and numbers should be thoroughly reviewed quite often and should be negotiated with the customer for any changes. The process of having a adjustable project plan is the key to reduce lot of stress for the entire team, including the customer.

Before I discuss about stress, let us review some of the commonly adapted software estimation techniques and their pros and cons.

1. Many projects use unscientific estimation techniques, which are mostly the "gut feeling estimations" and this leads to estimations being way off the right path. The poor estimates are either due to lack of skills to estimate or inability to think through risks and consider the risks during estimation.

2. In order to mitigate the risks due to unscientific estimation technique, shown above, many teams simply add 20% buffer to the total effort before submitting the estimates to the customer.

3. There are some light weight estimation techniques like Wide band delphi, planning poker using fibonacci series, relative estimation techniques, etc. which are found to be more accurate than the gut feeling techniques.

4. As per the cone of uncertainty, actual duration to complete the projects can be 4 times or 1/4th of the initial estimations. So, if one has to ensure a guaranteed delivery of the product to the customer, then the development team should do an optimistic estimate and multiply the number by 4 before committing the delivery date to the customer. Even though this theory is supposed to hold good for product delivery, no customer would agree with this model.

Moral of the story: So far no body has been able to come up with a model/formula which can give an accurate estimate and estimates remains as guesstimates most of the time.

Ok, Why is it not possible to give an accurate product delivery date and time to the customer ?
Because, it is we(human beings) who develop softwares. Until human beings are in control of software development one cannot give accurate numbers.

But Why ?
Because human beings themselves are controlled by forces of nature.
What are these forces of nature ?
Basically these are our surroundings, our friends and family with whom we interact everyday, our own emotions which are controlled again by our surroundings, etc.
Examples include : employees can fall sick forcing them to apply leave without any notice, government can change rules which can directly/indirectly impact personal productivity, natural disasters like earthquake, volcanoes can affect work etc

Ok so how is this related to stress ? Typically project plans are created at the beginning of the project and as described in the sections above, the PMs would add some buffer to the estimate before submitting to the customer. Major problem arises as this project plan and estimates are considered to be carved on stone without leaving any breathing space for natural forces to play. Even the 20% buffer on the optimistic estimate is not sufficient as natural forces cannot be predicted by %s.

The above said "Unnatural forces project plan" would be made as the guiding torch by the PMs to achieve the project goals. These plans are given to the developers to execute, which in turn forces the brave software development soldiers to fight every problem arising due to natural forces. These fights would in turn increases the blood pressure, heart beats of every team member. By the team the team reaches the end of the overshooted project, they would have won the half battle of the product delivery but would have definitely lost their mental peace.

How do we reduce this stress in above situation ?

• First and foremost, acknowledging that there are forces of nature and we as human beings are controlled by these forces, every second. This is not the other way around.
  
• As and when we see the blood pressure raising or the heart beat increasing, be aware that some forces of nature is casting its shadow somewhere. Bring this immediately to the attention of the customer and discuss the impact of this on the entire project. Try to make accommodative changes to the plan.
  
• If the customer does not understand or does not want to cooperate on reestimations, bring this issue to the notice of your superiors. They in turn could influence the customer.
  

Finally managing one's stress depends on choosing whether to cooperate and plan to work with forces of nature OR to drive against it. Finally you might drive against the forces and win, but at what cost ?

"Done" ness and "done grading" system

The concept of "Done" is not new to "Scrum"ilists. Scrum prescribes that a "Done" check list should be created by the team together with the Product owner. But still the Product owner has the final say in choosing if the iteration is "Done" or "not".

Many people argue against using the "Done" checklist, because they consider this to be non-Agile and also consider this checklist to increase the stress on the team !!!

How is it non-Agile ?
Its because, it goes against the Agile values and principles. Agile methods are based on the fact that project work is unpredictable and they suggest empirical control theory of learn and adapt cycles. Now in case of "done" in Scrum, the product owner(PO) goes through the "Done" checklist, and sets an expectation for the team to achieve certain things by the end of the iteration. If the team is able to deliver "all" the things in the checklist an iteration would be termed success or could easily be termed "failed" iteration.

But don't you think "enforcing" "done" on the iteration is like enforcing the people to think that "everything in a project is predictable".

So, can we abolish "done" checklist and give a free hand to the team to do whatever they want to do ? How do we measure if team is really on the right track ? how do we know if the team is doing things which adds value to project ? How do we measure the quality of the iteration ?

Here is what Jeff Patton wants to say about measuring quality of iteration.

Jeff Patton recommends a grading system for features in an iteration. :

1. In a small group, brainstorm the major features of your product.
2. Independently for each feature write your "grade" for the quality of the feature. Answer the following questions: Do you like the feature?; Do you like using it?; and Is it a valuable part of the product? Let your answers help you grade the feature with an A, B, C, or D, or fail it with an F.
3. When done, discuss your grades with those in your group. Agree on a grade that best represents the group's opinion of the quality of that feature.

After looking at the recommendations of "done" and "grading", I have been thinking of proposing a new model providing the best of both worlds. I am going to call this as "done grading" system as this is a mid way between the above two theories.

Here are the steps I propose:
1. At the beginning of each iteration, the team would sit with the PO and create the "done" checklist. This checklist is created to understand POs expectation for the iteration. I feel having "done" checklist sets the right expectation and provides a clear goal for the team to proceed further. Without a clear goal, the team would still be working but without a common goal.

2. At the end of each iteration, the PO would still go through the "done" checklist, but instead of calling it "yes" or "no", he/she grades the iteration based on completion of tasks.

For ex: if the team has following tasks in their "done" list

1. delivering A,B,C features
2. unit tests for all features
3. regression test cases and testing
4. automating the tests
5. Introducing TDD
   

and, If the team has partially achieved the above goals, then the PO can chose grade as "A", "B" or "C", etc based on his satisfaction. Once the grading is done, and during the Iteration review session, PO would sit with the team to do a root cause analysis for poor grading of tasks. This session, provides rich inputs to the team, and this data could be utilized to improve the grading in the upcoming iterations.

By applying the above mentioned "done grading" system, the team is relieved of "stress" at the end of each iteration . This is because the iteration would be measured on a more collaborative way of "done grading" system rather than the earlier binary "done" system.

Agile conference in Oralndo, FL December 3 - 6

Agile Development Practices
December 3-6, 2007 * Orlando, FL
Shingle Creek Resort
http://www.sqe. com/go?adp07ng

Conference Web site: http://www.sqe. com/go?adp07ng
Master Schedule:
http://www.sqe. com/agiledevprac tices/Schedule
Download Brochure: http://www.sqe. com/go?adp07broc h
Keynote Sessions:
http://www.sqe. com/agiledevprac tices/Keynotes
Pre-conference Tutorials:
http://www.sqe. com/agiledevprac tices/Tutorials
Concurrent Sessions:
http://www.sqe. com/agiledevprac tices/Concurrent
Register Now:
http://www.sqe. com/agiledevprac tices/register

************ ********* ********* ********* ********* ********* ********* ****
**

WIN A REGISTRATION
Win a Registration to Agile Development Practices 2007! Request a
brochure or register for the conference by November 9, 2007 and be
entered to win 1 of 10 complimentary full conference registrations!

Click here for full details! --> http://www.sqe. com/go?adp07cont ng

Wanting to go to the conference but not sure if there is money left
in your training budget? Try your luck and enter the drawing for 10
complimentary registrations. Attend Software Quality Engineering' s
first Agile Development Practices conference to hear from some of the
best experts in the business. Choose from over 75 sessions to build
your own information- packed event complete with practices, processes,
technologies, and leadership principles geared for agile software
professionals.

************ ********* ********* ********* ********* ********* ********* ****
**
SPECIAL DISCOUNT
Save up to an additional $100 off your registration fees when you use
promo code NGAE during the registration process. For more
information, call 888-268-8770 or 904-278-0524.
************ ********* ********* ********* ********* ********* ********* ****
**

We're pleased to announce Software Quality Engineering' s first Agile
Development Practices conference coming to Orlando in December.
Whether you're investigating or implementing agile development
practices, processes, technologies, or leadership principles, this
new conference has solutions for you. Brought to you by the producers
of the STAR conference series and the Better Software Conference &
EXPO, you have our guarantee that you will experience the first-rate
quality and commitment that have defined Software Quality
Engineering' s conferences for the last 15 years.

Brochure Now Available
Download the brochure now to build your own conference from over 85
sessions.
http://www.sqe. com/go?adp07broc h

Don't Miss Out on the New Open Spaces Sessions
Want to discuss a topic that is not on the program? Great! You need
Open Spaces. We supply the room and the chairs. You supply the ideas
and the leadership. Choose a topic you'd like to discuss, pick your
timeslot, promote your topic at the conference, enroll others, and
have a ball.

That's what Open Spaces is all about—you are in charge of your
learning.

The basic principle is: Everyone who comes to an Open Space session
must be passionate about the topic and willing to take some
responsibility for creating learning out of that passion.

Five other key principles are:
1. Whoever attends is the right person.
2. Whatever happens is the only thing that could have happened.
3. Whenever it starts is the right time.
4. When it is over, it is over.
5. The Law of Two Feet—If you find yourself in a situation where you
aren't learning or contributing, go somewhere else.

If you've never tried Open Spaces, do it now. You'll teach and you'll
learn.

For registration information, please email sqeinfo@sqe. com or call
our Client Support Group at 904-278-0524 or 888-268-8770. To register
on the Web, visit http://www.sqe. com/agiledevprac tices/register

Agile in Product Company Vs Services company

During many of my Agile presentations, I keep getting the similar question from participants, "Can Agile work in services company" ?. My answer has always been "Agile methods could be implemented whether it is product company or services company".
I kept wondering where this misconception is coming from ? I think I have some clue here. ..

As we know, the software services company would try to cater to the needs of multiple customers. Many of the companies would be working on multiple projects ranging from Java/J2EE to COBOL, AS/400, etc. The verticals would be from retail domain to Avionics. As far as I have seen in Indians services company, each project is controlled by the customer's project team from distant locations. Even though the PM and the developers form the major crowd in the team, they have very little say in major project related decisions like choosing tools, process, etc.
The vendor software company has to negotiate with each of the customers about process, tools, methods, etc. Even the management of vendor companies cannot put their foot down about ideas because, there is a tough competition in the market. There is a fear that, many customers can walk out if they find any resistance to their own ideas. Keeping the above factors in mind, it becomes difficult for services companies to convince each and every customer about Agile method or any similar thing. This also results in poor implementation of methods like Agile in services organization. According to me, Agile methods can work successfully in services company provided there is a good support from not only from the vendor management but also customers .

Where as in product development companies, there is one team at the organizational level making all decisions about software development. If the management team is convinced about Agile, that is enough to take the idea forward with less resistance.

XP Day Manhattan - Oct 13th 2007

Upcoming XP Day conference in North America would be held on Oct 13th. Here is the note shared by Niraj Khanna of Diaspar software about the upcoming XP Day Manhattan program:

Diaspar Software and Thoughtworks is proud to present another
installment of the XP Day North America series: XP Day Manhattan
taking place on October 13, 2007.

The focus of XP Day is to bring top extreme programming practitioners
to North American XP communities to share their successes, failures
and perspectives on how to release high-value software sooner.

Our program for Manhattan includes:
1) A keynote address by Steve Freeman. Steve is a fixture in the
London software development community, a regular organizer of the
original XP Day, well known for his contributions to test-driven
development practice and co-recipient of the 2006 Gordon Pask Award.
2) A tutorial by JB Rainsberger, a recipient of the 2005 Gordon Pask
award. JB will talk about why XP works using the Theory of
Constraints model developed by Goldratt.
3) A tutorial by George Dinwiddie, a respected member of the XP
community, and author of an insightful blog about coaching XP teams:
http://blog. gdinwiddie. com. George will talk about sustainability at
multiple levels in XP.
4) Open Space. There’s plenty of room, the space is superbly run and
the conversation is lively. Collaborate intensively with both local
and invited advanced practitioners on issues that interest you most.

Cost of the conference is $249 US)and includes breakfast and lunch.
Registration is limited to 100 attendees. To register visit http://
www.xpday.info. For group rates, contact me at the address provided
in the header of this message.

Check out the following links for pics of our last conference: http://
tinyurl.com/ 2ysz6v and http://tinyurl. com/23ktwx

11 Ways Agile Adoption Fails -- Jean Tabaka

Jean Tabaka a great writer, Agile coach has written a good article on reasons behind failure of Agile adoption in organizations. Read the complete article here

In fact my previous article published on Agile Journal covers many of the above points and I can say the article compliments it.

Craig in UK conducting Agile Projectmanagement course

Craig larman guru in Agile methods would be conducting the course on Agile project management in UK. UK Readers of this blog can avail this opportunity. More information about this course is available here. Also there are some giveaways for early bird registrations and you can use this quote SKIL-PTC671 to get all those early bird prices.

Rupee Appreciation and Agile/Lean practices

One of the hot topics being discussed in the Indian IT sector is how to beat the rupee appreciation against dollar. Here is an article explaining various moves by Indian software giants to handle the current rupee appreciation issue. Most of the decisions taken by these software giants are the ones usually taken during financial crisis. These decisions include laying off employees, asking employees to work overtime with no extra pay, or increasing the hourly rate for the customer.

My view is, one could effectively utilize the dollar earned during every hour by incorporating Agile and Lean practices. Some simple practices(as explained in many of the Agile and lean books) include,
1. Project managers sitting with their team rather than in a far off cabin. This reduces waste due to frequent walking up and down by the team members to PM's cabin.

2.Having enough supply of coffee, tea or snacks within each project room. Otherwise, a lot of time gets wasted when the team goes to a far off cafeteria. As it is evident that even though the customer is billed for 8 hours per day, effective value generated is only worth 6 hours(Ideal Engineering Hours) . The wasted 2 hours can be effectively utilized in situations like the rupee appreciation issue impacting Indian IT sector.

3. Improving communication and collaboration using tools like Wiki, Skype, etc.

4. Redirecting the investments on expensive tools and looking at simple solutions such as usage of digital cameras, white boards, post-its.

5. Improving quality of code and reducing defects by early and continuous integration.

6. Applying the engineering practices like Test Driven Development & refactoring right from the beginning of the project.

and many more...
bottom line is, one could start fixing the issue internally by adopting the right processes, which adds value to the customer rather than applying the usual "inside the box" solutions.

Money transfer to friends and family made safe,quick and easy.iKobo Money Transfer is a new method of remittance that is easier and more secure than sending money orders

Absolute estimates and Relative estimates

As soon as you ask any software developer about the effort it takes to implement a particular requirement, the answer would be either in hours or days. This is called absolute estimate and in the agile world the concept of relative estimate has been introduced by Mike Cohn(atleast as far as I know !).

In case of relative estimates, one would estimate the size rather than the effort relative to each other and then, this size could be mapped to effort based on the velocity/some other means. But the key thing is to understand the applicability of relative and absolute estimation techniques.

Story points are the units used frequently while applying relative point estimation technique.

Coming to the applicability part, the business people want to know how many days or months it would take to deliver the product. You can't tell them that the requirements takes 55 story points, these numbers may not help them to allocate budget or prepare themselves to market the product. They should always be given the absolute estimates. But, the route to absolute estimates at this point should be through relative estimates. This is because, as we move higher the abstraction the clarity reduces and accuracy with absolute estimates decreases. At higher abstraction levels relative estimates suit better than the absolutes. The maturity of the team lies in converting these relative estimates to absolutes and sharing with stakeholders.

Generally, product planning, release planning phases are at higher abstraction level than the iteration planning phase.

At iteration planning level, one has more understanding of requirements and can be more accurate in providing the absolute estimates.

Trends in Software Development methodology

Here is a good article about the changing trend happening around software development, what business people are thinking about software development methodologies and much more... Check out the following article

Thinking like Scrum Master

Most of the time our behavior/attitude would adjust automatically to suit a particular role or designation. For example, If somebody is a senior developer he would be spending time thinking only about solving a technical problem, he wouldn't worry or think about leading a team most of the time. His thinking gets limited to certain area of his responsiblities only.

Similarly, as one is promoted to become a project manager or Scrum Master, thinking patterns would automatically gets adjusted to lead the team and showing attributes of a leader. Fundamenally people wait for suitable title/designation and then would try to change their thinking patterns, atleast most of the times !!

Recently, Pete Behrens one of the Agile practitioner suggested a good thought in the Agile discussion group, and thought I would share here:

If you wait for a title to behave as that title you will rarely make it
there - rather if your act and behave what you want to become,titles become
some what irrelevant.

Microsoft release eScrum tool

Finally Microsoft seems to be encouraging implementation of Agile methods across its projects, and predominantly Scrum. They have gone a step ahead and have created this Scrum tool too. Read more information about this tool here. Even though this tool seems to have been created for internal project purposes, chances are their that they can commercialize it.

Right now, RallyDev, VersionOne seems to be leading the Agile PM tools bandwagon.

Performance Appraisal - Different perspective

Here is a nice quote from Ester Derby about performance appraisal:

"Performance is *not* solely a matter of individual skills. Performance is a function of the person *and* the environment. Policies, procedures, structures (and dare I say it) the quality of management all affect individual performance."

     -- Esther Derby"

What Every Manager Should Know About Feedback

Right now many companies are going through performance appraisal cycle, and the managers are supposed to give their feedback to their team members.  How should one give an effective feedback ?.  Here is a good article by Ester Derby on how to effectively give feedback to others. This article provides a clear difference between an evaluation/judegement and a feedback.  

 

Meeting Effectiveness

Recently I attended a European-Indian business summit and I was representing my company Valtech. Many Italian, Spanish companies were visiting India and were look for possible business partners.
The meeting slots were pre planned/agreed and were circulated prior to the meeting. The time slot was time boxed for 30 minutes each. Separate stalls were set up for each of the EU companies, and during the specified time slot, the representatives from the Indian firm would go to the stall and have a discussion for 30 minutes.

3 of us from Valtech, met nearly 10 companies in 2 days. An important thing I noticed in the summit was the time boxing of meetings for 30 minutes. I have never seen such an efficient meeting happening from my earlier experience. During the meetings with prospective customers, we were able to make out if this is a make or brake deal and within the first few minutes itself.

Somewhere I read that most of the decision happens within the first 15 minutes of the meeting. So, I think any meeting intended towards making some decisions, would be effective it

• it is time boxed
• lesser the time, the better
  

More info. on meeting effectiveness
In one of the Agile forums, Mark Herschberg gave the following tips to improve the meeting effectiveness:
1) Set fixed time limits. I learned this from scrum meetings where we had a
kitchen timer with 15 minutes to force everyone to be efficient. Even for
longer meetings this has been found to be effective. Even if your meetings
aren't any shorter. the act of having a timer visible on the table and
counting down helps to focus people.

2) Have an agenda. Often meetings don't have a clear agenda. Even if
people know what the meeting is for (e.g. our weekly status meeting) it can
be a bit vague and fuzzy. Every meeting should require the following:
a) These are the issues to be discussed
b) These are the questions we will have answered by the end of the meeting

3) Have a clear understanding of when questions should be discussed. Often
people get side tracked as various issues come up in meetings and people
wander down a particular thread. By knowing when and where an issue can be
discussed, it's easier to say, "that's a very good issue, why don't we
address that in X meeting which is for such topics." Everyone needs to know
what meetings there are and what each are for. I'm debating creating a
"catch all" meeting once a week at my current project so if there's anything
we miss, we can always say, "put it in the catch all meetings."

4) Build a culture of efficient. Make everyone want to have fast, efficient
meetings, and empower everyone to be able to suggest moving a topic to a
different venue,

5) Recognize that there is value in inefficiency. Fast, to the point
meetings, while generally effective, sometimes miss that creative spark that
comes from getting side tracked, from the random threads that usually are a
waste of time, but once in a while yield a great insight. (This is one of
the reasons I'm looking at a "catch all" meeting to capture some of the free
form creativity.)

DBUnit Mind Map

From the last few days I have been testing DAOs using DBUnit. During the process of learning, I created the following Mind map. I will keep updating this mind map as and when I learn something new.