Day 2 of Agile Bengaluru 2010

I attended TOC and JIT session . This session was intended to teach Theory of constraints and in turn identify the bottlenecks in projects. I liked the way the session was structured.

This session also included a small hands on workshop where in the participants form small groups and would pick a project to work on. Within each group, the participants would work on identifying the bottleneck and how throughput could be increased by reducing the cycle time.

I also got a chance to listen to Jeff Patton during one of the breaks.

I had a few Aha moments while listening to Jeff. Here are some points which has put me to ponder for the next few days

1. Requirements are considered to be harmful. Read Jeff’s popular whitepaper here to understand why he says so

2. The projects would always lead to failure as long as we have the You and US mentality between the customer and the software development team.

I also got a chance to meet Bas Vodde, who happened to be in Bangalore and just walked in to say hi to Jeff and Dave.

Bas and Craig Larman (my Guru) have written various books and white papers. I highly recommend the recently released book Scaling Lean and Agile.

Day 1 of Agile Bengaluru 2010

Just returned home from the ASCI Agile Bengaluru 2010 session. The event was well planned and organized.

The session started with  David Hussman’s Discovery and Delivery - Redesigning Agility.

I realized that every presentation by Jeff Patton and Dave revolved around discovery and Delivery.

Next session that I attended was by Jeff Patton. He is a very knowledgeable guy and  I enjoyed his session on User Story mapping. More info about this technique can be found here. 

 

Here is the gist of the session

Most of the time people relate Features to User stories, which is a big misunderstanding. People with this misunderstanding, and continuing to gather requirements in the name of user stories would end up creating bucket of features list.

One of the key point I learnt from Jeff’s session on User Story mapping was the importance of the good facilitator. During the user story mapping workshop, he was able to gather the stories by asking the right set of questions.

Don’t get bogged down by the formula

  Nowadays it is increasingly becoming popular to follow the user story template 

 

 

 

As a [role], I can [feature] so that [reason]

However, Jeff made it clear that there is no harm in using the above template however don’t get bogged down with this formula. Understand the intent behind the above template and create the stories in your way.

Jeff also touched upon the importance of Personas.

Blogger Labels: Agile,Bengaluru,ASCI,Delivery,presentation,Jeff,Patton,Dave,User,Story,info,technique,Here,gist,Most,Features,People,requirements,bucket,importance,facilitator,workshop,formula,Nowadays,template,role,Understand,Personas

An open source Agile Project Management tool - Express

Came across this new Open Source project management tool called Express.  This tool seems to be still in beta development.

More details below,

Express is an Agile project management tool. The web application is written using Flex while server-side component is a Spring based Java EE application.

You can download the same from here

Following are some of the screen shots of the application

Backlog management screen

Virtual wall

100 Impediments while implementing Agile methods

Every Agile project has some impediment in one form or the other.

• It could be the organizational policy like individual appraisals and rating encouraging competition among the team members killing the team unity
• People related issues, like the command and control Scrum Master not letting the team to make decisions
• Tools and environment issues like the lack of automation and lack of skills in using tools,etc

We could list out many more...

I came across this article which lists 100 impediments that is constantly seen on Agile projects.

This website classifies various impediments into categories.

Recommitment cost - Waterfall Vs Agile

Whenever some one makes a promise, the cost of apologizing begin to grow. Whenever one feels that promise cannot be kept, the cost of recommitment starts to grow. The cost depends on the stage at which recommitment is done.  If the apology and the recommitment is done at an early stage, the cost is going to be less. If not, it is going to grow exponentially inflicting economic and emotional damages to the people involved. 

Consider a situation where a Project Manager(PM) of a software company promises to deliver a component on a certain date to the customer.  During the development, if something breaks down(and the remedy to this problem is beyond the control of the PM) then the PM has two options in front of him/her.

1. Option 1: Inform the customer immediately and face the consequence
2. Option 2: Don’t inform the customer and try your best to fix the problem over a period of time.

With the option 1 above, customer may or may not become happy to hear about the problem. Some customers are happy to see the PM bringing the problem to their notice at an early stage. This in turn  provides them an opportunity to make alternate arrangements in the face of this problem. However, a few customers could get upset as many of them don’t like to hear about the problems.

Option 2 is typically applied when there is sufficient time for delivery.  Since the customer is not aware of the problem, the PM could assume that some how he/she would take help from somewhere and would fix the problem before customer notices it. Since customer is not aware of the problem and sufficient time is left, there is no pressure to fix the problem immediately.

Option 2 mentality is typically seen in Waterfall development teams.

As per Fred Kofman, most of the teams who follow Option 2 fail in some way or the other. He continues to say that,

Unfortunately these hopes do not always become realities. The work falls further and further behind, while the creditor is in the dark, unable to hedge against a risk he knows nothing about.

Fred calls the hope of people with Option 2 thinking as Self serving rationalization.

How does this relate to Agile ?

The Agile practices are structured in such a way that, opportunities are provided on a daily basis to bring up the issues upfront. This could be either through the Scrum meetings, reviews, or retrospectives. This is nothing but exercising Option 1 mentioned above.  This in turn removes any hopes fulfilling self serving rationalization and in turn reducing the cost of  apologizing and recommitment.

Tim Lister on Agile Leadership

Recently I watched this informative video by Tim Lister in which he speaks about Agile project leadership. I would highly recommend this video for all Agile practitioners.

As we know, Tim is the author of the two greatest books of this decade.  They are

I made some quick notes for myself while watching this video, and thought would share the same here.

1. Process is something you do naturally. Real process is  something you do when you are under pressure.

2. A Leader is someone, who by dint of words and or deeds,influences the behavior of others

3. Great Projects have emotions

4. Software development could be compared to an orchestra.  Both Orchestra and Software development involves different types of people, and even if one or two don’t perform well, everything goes for a toss. 

5. It is really hard to hate when you know the name

6. Cross Pollination is critical. Ex: Americans and Canadian. Even though they speak the same language, still they feel different.

7. Question: How do you keep the teams motivated ?
Tim : Teams thrive on Interesting Problems. Teams cannot be motivated by giving more salary.

(Rephrased in my own words)  For ex: if some one is given 2000 USD rise, the developers won’t jump in and say that from today onwards I am going to be more productive.  Maximum thing they would do is call their family and take them for dinner and forget it as though nothing has happened. 

8. Every leader has to groom another great leader

9. in Hitachi, every project team has to try something different. The management rejects if the project planning is done in a way similar to others.

10. CMM is score card to rate the process

11. If you are just doing what Agile methods say, you are already at CMM level 3 

12. Hockey is Un-Choreographed Ballet Dance.  This could be compared to Agile. While on the field the players have to think about various situations and make dynamic decision. The coach cannot guide each and every move of the players.

Agile Bengaluru 2010

The Agile Software Community of India (ASCI) is organizing the 2nd Annual Agile Conference in Bengaluru on 22nd and 23rd Jan 2010 named Agile Bengaluru 2010.

For the first time in India, we’ll have 4 Gordon Pask Award Winners at a single conference:

• David Hussman
• Jeff Patton
• J. B. Rainsberger
• Naresh Jain

The conference theme this year is “Post-Modern Agile - Be done with the Dogma“. The conference is really targeted at Agile practitioners, who want to explore ideas beyond the basic Agile stuff.

Also this year, for the first time, we are hosting the World-famous Programming with the Stars contest during the conference.

After the standard proposal submission and review process we have the final conference program published - http://www.agileindia.org/agilebengaluru2010/agile-bengaluru-2010-program.htm.

If you are interested in participating in the conference, hurry up and register for the conference here: http://www.agileindia.org/agilebengaluru2010/agile-bengaluru-2010-registration.htm We have limited 125 seats total.

Also for those who cannot attend the Bengaluru conference, don’t worry. We have another conference in Mumbai. Check out: Agile Mumbai 2010 Conference.

Please use the #agile_bengaluru_2010 Twitter tag.

Moving from Waterfall to Agile – Some tips

 

If you want to make enemies, try to change something             -    Woodrow T. Wilson

Transitioning from waterfall to Agile is not only a big change but also a change that needs to happen at an organizational level. Leaders leading such changes need to have a clear vision about the end goal and need to effectively communicate the vision to all.   Lack of clarity in the vision and communication leads to creating more enemies than friends.

A CEO of an organization could command all projects to start practicing Agile immediately. Most of the employees have no choice but to follow the command. However employees who are not sold to this idea won’t be doing the work by putting their heart and soul in it. This change will die down over a period of time and such organizations will never be able to bring a new process change like Agile.

In order to effectively bring Agile into an organization, one has to identify the areas of resistance and meticulously handle them.

Always remember 

Resistance creates Persistence

Here are some of the tried and tested techniques for bringing organizational changes :

  Share the big picture with the employees
  Share the reason for the change and its benefits for the   organization       
  Trust the team implementing the change  
  Do an incremental change rather than big bang approach   
Provide the necessary support for implementing change (logistics, training, etc)  

Understand the groups who could resist the new changes and tackle them 

Some great articles have been written by various thought leaders about bringing organizational change.  Here are some of them:

    Communicate, Communicate, Communicate
    Managing Change
    Organized Change
    12 Important elements of change management

Leaders do mistakes while bringing process change (like Agile) into organization.  This article lists the common mistakes that leaders do while implementing the change.

Summary

An organization deciding to embrace Agile shouldn’t rush with the big bang approach. One needs to have patience and use the incremental approach.

My experience in helping organizations in transitioning from waterfall to Agile says, it could take any where from couple of months to a year or two for a complete transition. 

Need for Retrospectives

Every organization and every project has some grapevine running in the inner circle. When I say Inner circle,

it is the closed group of people who trust each other.

For ex: In a typical software project,  a manager(PM) with command and control attitude, would encourage creation of inner circle with project team members, whose opinions are being ignored by the PM. This inner circle group  excludes the manager.  This group in turn talk among themselves and share their agonies without the knowledge of the manager.

Above example of team member inner circle group, can be extrapolated at an organizational level with inner circle being the employee group excluding the management of the company.

The inner circle groups mentioned in the above examples are harmful for the project and the organization. They get created as they don’t have any venue to express their bottled up emotions/thoughts/opinions. This in turn leads to a lot of negativity. This negativity needs to be conquered sooner than later. Here is a good article, which provides techniques to conquer such negativity.

One of the ways to conquer the negativity is to provide a platform for the employees to express their thoughts/opinions/emotions. In Agile projects, retrospectives provides such a venue. This in turn leads to healthier project and teams in a longer term.

Difference between Sprint and Iteration

“Iteration” is commonly used to term in all Incremental and Iterative development methods. 

However the word “Sprint”, which has similar meaning to iteration was coined in the Scrum method. Mostly the Scrum practitioners use the word Sprint. Even though many people use the word Sprint and Iteration interchangeably, there is a notable difference between the two.

Sprint as defined in pure Scrum has the duration 30 calendar days. However Iteration length could be anything as defined by the team.

Introducing new concept – Innovative way from Google

Bringing change is not easy, and people resist changes. Top ten reasons why people resist changes can be found here. Nowadays new processes and technologies keep getting invented everyday and the employees need to be up-to date with it to be competitive.

Introducing the new concepts is not easy. Thought leaders have come up with several patterns too to introduce changes in the organization.   However recently I came across this article Testing on Toilet, which talks about the innovative way being used in Google to teach their employees testing and bringing new change.  As per the author,

A regular weekly(ish) tip posted in toilet cubicles and above urinals. Short enough to be read whilst doing your business

Even though the above method looks odd and radical, trust me at the end of the day, developers would definitely learn something good and remember it for a long time.

Here is one of the actual pictures taken in the Google toilet giving some tip about testing certification

Agile Certifications

Suddenly I am seeing a spurt in activities around Agile certifications. Scrum Alliance is working seriously with various thought leaders in coming out with new certification criteria.  There is another organization World Agile Qualifications Board(WAQB) coming up new Agile certifications.

Hope all these people come together and have one certification at some point of time in the future.

Glossary of Scrum terms

Scrum being the most popular Agile methods, a lot of new Scrum users either are getting distorted definition of many Scrum terms or have total misunderstanding of the terminologies. 

To avoid such misunderstandings, Scrum Alliance has glossary of 39 key Scrum terms

Scrum FAQ

Following questions are frequently asked by the novice Scrum teams. I will keep updating these questions and answers as and when I get it.

1. Can we have single Scrum Master(SM) for multiple projects ?

Answer: It is recommended to have a dedicated Scrum Master for each project. Diluting this could also dilute the effectiveness

2. Can Scrum Master be a Product Owner ?

Answer: Scrum Master should never be a product Owner.

3. Can Scrum Master be technical and can SM help the team if they are stuck with technical issues ?

Answer: It does not matter if the SM is coming from technical background or management. However if SM is technical, he/she should be careful enough not to dilute the SMs responsibilities in the process of helping the team with technology stuff.

4. During the Scrum Meeting, my colleague talked about an impediment and I had the answer. However, can I answer it immediately and it won’t take more than 1 minute ?

Answer: Don’t diverge from the recommended rules around Scrum Meeting. Any discussion should happen outside the Scrum Meeting. Even though your answer takes only one minute, some one else could also jump in saying even he/she needs a chance to answer another question. This leads to chaos and could stretch Scrum Meeting beyond recommended limit of 15 – 20 minutes. My recommendation is to follow the rules by the book until every one gains experience.

5. I just need another 4 hours to complete my task and the iteration is coming to an end, can I stretch the Iteration/Sprint duration ?

Answer: No. Iterations are time boxed.

6. When people say Sprint duration is 30 days, is it working days ?

Answer: Sprint duration of 30 days means 30 calendar days.

7. The team has completed all the tasks before the sprint ends, what should they do now ?

Answer: The team can approach the product owner and request for additional items from the PB.

8. Is it mandatory for the team to follow the Idealized line in the burn down charts ?

Answer: Idealized(A.K.A Ideal) line provides just a point of reference.

9. Can I work on the undone tasks in the next iteration ?

Answer: Undone tasks would go back to Product Backlog and Product Owner would make a call on the set of requirements for the next iteration with due feedback from the team.

10. Should I use Iteration or Sprint ?

Answer: All sprints are iterations but not all iterations are Sprints. Sprint is the terminology coined by the Scrum co-founders to define an iteration.

========================================

P.S: If you are aware of more questions and answers, feel free to send me and I would post it here.

Getting the estimations "accurate" in one go – a vestige

A team adopting Agile method for the first time tends to do many mistakes during the initial days. One of the common mistakes is about trying to do accurate estimation. During the Iteration Planning Meeting(IPM) of the first iteration, the team does not know their velocity and tends to spend time trying to come up with “accurate” estimates or estimates with additional unscientific buffers. They tend to spend too much effort detailing out tasks and estimate them.

Agile methods discourages teams spending too much of effort on reaching perfection in one go, especially around estimations. It recommends teams to apply the empirical control model by frequently inspecting the estimations and adapting them.It recommends to go with daily re-estimation technique.

Daily re-estimation

Agile methods recommend that

• During the IPM, estimation for the requirements should be done with whatever knowledge one has at that point of time
• While doing the daily re-estimation try to steer and come up with more accurate estimates
• Use the optimistic estimates rather than the pessimistic estimates

Subsequent Iterations

Right from the first iteration, the team must track couple of key parameters, For Ex:

• Planned effort Vs actual effort
• Number of committed stories Vs actual stories delivered
• Number of new tasks discovered during the iteration
• Planned resource budget Vs actual resource budget

Once the team gets to know their velocity, the future iterations could be estimated and planned in a better way.

Conclusion

• Trying to detail out all tasks, trying to provide accurate estimations, detailed planning and analysis are the vestige coming from the waterfall model
• Agile recommends frequent delivery of working software rather than wasting time on analysis-paralysis

Potentially Shippable product – A Myth or Reality ?

 

Scrum defines that, at the end of each sprint potentially shippable product (PSP) should be ready. 

Ken defines this product as

Sashimi, a thin slice of product which contains all aspects of the product

Let us closely watch the iterations/sprints happening around us and  do you see a sashimi kind of product at the end of each sprint ?

I have not seen many  …

Most of the times I have observed that the sprints end with all the features being coded but testing, defect fixing spilling over to next sprint. This results in not having a potentially shippable product. There could be many other reasons in addition to the above but time and again, Agile projects end up with incomplete sprints and that is the reality.

You might ask, if each sprint ends up with an incomplete work, when can we see a stable product  ?

Answer is the work around invented by the thought leaders. It is called Stabilization sprints.

What are stabilization Sprints ?

These are sprints dedicated towards tasks such as

Defect fixing
Fixing technical debts
Completing any final rounds of testing
Update or fix any architectural issues
Getting ready for the release by completing release notes, etc

Stabilization sprints can be scheduled based on the need of the hour. There is no hard and fast rule around when it should be scheduled.

Many people call stabilization sprints with different names based on the specific activity being executed. Some names are, Testing Sprint, Technical Debt sprint, Analysis Sprint, etc

Is it a right approach to have stabilization sprints ?

Some people believe that Stabilization sprints are Scrum’s Anti Patterns. The suggestions given at various places to solve this anti pattern is to define Done properly. The product owner is expected to set the right expectation for the team during the planning meeting through Done.

Conclusion

• It needs a lot of discipline to deliver a potentially shippable product during each sprint. 
• Even though stabilization sprints are not recommended, it seems to be the reality

Continuous Deployment – What is the limit ?

I have heard about project teams still coming upto speed on daily builds and many are still living with nightly builds. 

For many continuous integration is still a dream. It is a proven that practice like building and testing the code continuously helps to improve the ROI in the long run. 

What about Continuous Deployment ? How many times a can you deploy ?   Even though setting up build and continuous integration is one time effort, it is the discipline that makes the build and continuous integration process to work.  If you want to learn about such a disciplined system,  read how the continuous deployment is done fifty times a day at IMVU from here

Need for matured developers in Agile Teams – A Myth

I have heard many times from in-experienced scrum coaches saying Agile projects need matured team members. The Big myth The above statement is as big a myth as the one which says Agile projects follow no documentation The answers I got… I had asked one of those in-experienced scrum coaches the following questions,   What do you mean by Matured team members ?    Why do you think Agile projects need more matured team members ? The answers surprised me a lot, the answers were    Matured team means, a team with more experienced people      The reason we need matured teams is because, concepts like self organizing teams and self managing teams are easily understood and implemented  by experienced developers as compared to juniors. They also say that the junior developers mis-use the freedom and trust shown in Agile projects and so, they are not suitable !! Does maturity comes with Age ? My view is, maturity to a person does not come with age or more experience at work.  Secondly, concepts like self organizing and self managing teams need the fundamental value, trust to succeed than any software development skill or experience. I strongly believe that, individual team members shouldn’t be blamed. This is because, the culture followed within the team is strongly influenced by the person leading the team. According to the greatest thinker, Peter Senge, We must look beyond individual mistakes or bad luck to understand important problems. We must look at the underlying structures which shape individual actions and create the conditions where types of events become likely So, if a junior team member is not doing his/her assigned job, instead of blaming him/her, we should look at the system which is driving this character within them.

Conclusion

Success of Agile projects does not depend on the experiences of the team members but on the fundamental value driving the system.

Key Do’s and Don'ts in Scrum

 

Even though there are several  rules and practices in Scrum, but still they don’t  cover all contexts. Practitioners keep coming back with several questions like,

We don’t have a scrum master yet, can we   make the Product Owner as the scrum Master ? Can we have a single Scrum Master for several projects ? and several others ….

So, here are some of the answers to questions like the ones mentioned above 

Here are some of them

• Scrum Master ideally should lead only one team and the same thing applies to Product owner.  If they are leading more than one teams, their effectiveness decreases by the same fold
• Don’t let Scrum Master to wear the cap of  product owner too
• Don’t let one of the team members to take the role of Scrum Master
• Even if there is a large team, ensure that there is a final product owner making final decisions about the product backlog
• When Scrum says, team size should be 7 +/- 2, this number does not include then Scrum Master and the Product Owner

Technorati Tags: Scrum,ScrumMaster,ProductOwner,7+/-2

Test your knowledge on Scrum

http://www.freedigitalphotos.net/

Ken Schwaber, co founder of Scrum has come out with an online program to assess Scrum Knowledge. This assessment checks purely "What" scrum is all about.

Here is the link to the program with the password

http://www.scrum.org/scrumassessment/

password : "assessment2"