User Stories - How detailed it should be ?

During the initial days of requirement gathering session, the product owners end up writing the epics. These epics needs to be broken further down into the user stories .   One common question repeatedly asked by the novice product owners is when is the right time to stop splitting the user stories ?   

If you Google around there are many articles written about this topic. 

Some of the options proposed by various authors include:

1.  Stop detailing when you feel the user story is big enough to be implemented in 3 – 4 days

2. Stop detailing when you feel the user story can be implemented in one iteration

3. Quite commonly referred acronym is the “INVEST” model.  More details about this model can be found here,   
    
I really like the INVEST model however,  if the Product Owners(PO) and developers are new to Agile, the above model will not help them much. I still feel that it looks pretty abstract to them.  

In one of the real world case studies, a group of “new to Agile”  product owners and developers  applying the INVEST model on user stories got into a debate for couple of days. They were not willing to budge with their own understanding of  “What testable” means, as each of them had their own explanation.  

So, just telling some one to follow the INVEST model may not be sufficient.

I have my own opinion about this,  while I am coaching the Agile teams, I recommend an iterative approach to detail out the user stories. Each time the user story is created, I ask the product owners to apply the INVEST principle to begin with and then share it with the development team to check their confidence level . If they are able to understand it easily and say that they can code this story, then probably it is the right size.   If not,  then the user stories needs to be split or detailed out further.  The developers take the important seat here. The developers need to review it because, they are the people on the ground implementing the same.

If the team is working in distributed model with POs  and developers distributed across the globe, then the POs could write the user story on Wiki or JIRA kind of tool . The developers on the other end can write their comments/questions as part of the feedback loop.

A good example of Collaboration

During the weekend reading, stumbled upon this fascinating article which talks about Collaboration  with a real life story.

 

 

 

 

 

Check this article out

 

 

 

Team work is needed, but one should not just nod for all requests. It could take the entire project down.

Funnier ways of implementing Agile projects

Have you observed that every company wants to be known as an Agile company(company implementing Agile methods), but no one wants to really follow Agile by the book ?.

Software Project teams do a lot of Agile tweaking during the journey of implementing Agile to fit the company’s culture. Since, company’s culture cannot be changed so easily, they tend to modify Agile practices to fit the companies needs.  Here are few and funnier ways of tweaking that I have observed :

1. Have start and end dates of project carved on stone, and all the requirements are then tried to fit in between the dates.  But, the coding, design and Test are done in 2 or 3 weeks cycle. All the new requirements that emerge during iteration has to be implemented no matter what within the duration

2. Measure Velocity week after week and set a goal for the team to achieve the velocity

3. Measure velocity of all the Agile teams and standardize the Velocity number (like number of story points to be delivered in an iteration) across organization

4. Project Manager would be renamed as Scrum  Master after the CSM training and he/she would continue doing what they were doing earlier

5. Testers are separated from the main team

6. Testing is done at the end of all iterations with a dedicated testing iteration

7. While signing the contract with the customer, sign the fixed bid contract based on the number of stories

8. Having an iteration duration of > 6 weeks

9. Staffing the project with all senior people with the assumption that Agile projects need only “matured” people. See more myths here

Photo credit: http://www.rgbstock.com/photo/mhAT2b2/so+happy+2

PMI is offering Agile Certification

Finally the PMI, big dinosaur as per agilists,  is offering the Agile certification.  Even though PMI is famous for its waterfallish process support, but its team looks like finally has woken up by the noise Agile methods like Scrum, XP is creating in the universe.

Take a look at PMI’s  Agile website for more details.
On and off, we keep hearing about  Agile certifications being offered by Scrum Alliance and other well known organizations. However, so far many of them have either not taken off successfully or have died down after a brief hype.    Now PMI, too seems to be planning to offer  Agile Certification, need to wait and see if it gains popularity.  check out the  PMI’s Agile Certification FAQ from here.

PMI seems to have taken help from Agile thought leaders like Alistair Cockburn, Mike Griffiths, Michele Sliger, etc  in making the Agile certification happen. These people carry a lot of credibility in the Agile world, and so, we could definitely expect a quality Agile certification from PMI in the end.

 

I still believe that these certifications will improve the knowledge but can’t change a man(or a woman)

10th Year Birth Anniversary of Agile

      Between 11th and 13th of February 2001, the lodge at Snowbird ski resort in the Wasatch mountains of Utah gave the space to Agile Manifesto to be born.  The 

17 people at this logde were not merely talking, relaxing and skiing. They were brainstorming about the issues that software developers (including themselves) were facing every day.  The final day took the birth of  Agile Software Development Alliance.

 

Read the story of Agile Birth here.  

Now after 10 years of  Agile invention, Alistair Cockburn  had organized a reunion event.

 

In addition, 16 out of the 17 signatories will take the stage on Aug 8th at  Agile 2011 Conference.     

During this conference, attendees will enjoy open access to all 17 stages hosting speakers, classes, workshops and special events, plus a stage dedicated to Open Jam: a place for problem solving and collaboration where anyone can convene a session, share questions and quandaries, talk to the experts, demonstrate software and techniques, and experiment with emerging Agile practices and ideas.  

Agile2011 promises a stimulating week of learning, collaborating, brainstorming, and sharing problems and solutions while networking and making valuable connections

Agile Vs Lean

There are a lot of articles on the net explaining the differences between Agile Vs Lean.  There are eternal debates about them too.  But this article AgileVersusLean by Martin Fowler gives the most simplistic explanation about the subject.
In the above article, Martin ends by saying I think of lean as a strand of thinking within the agile community, like a pattern in a rich carpet.

Picture courtesy: http://www.popgadget.net/2008/02/flexible_hanger.php

Importance of Cross Functional Teams

As per the Harvard Business Review professor Tiziana Casciaro, an expert in Organizational Behavior 

“Working with similar people leads to limited perspective and heterogeneous group brings different perspectives to the table and bring truly innovative approaches to solve a task” 


I guess this could be one of the key reasons of having cross functional team practice in Scrum.  In most of the Non-Agile projects, the teams are formed based on architecture layers.
For ex: UI team, Database Team, Middleware team.  

Each of the above is a homogeneous group and there is less innovation.  

However, most of the Agile methods recommend team formation based on the story or Requirement as opposed to the architecture layers.   This would encourage having team members from UI, Database, Middleware, Testing, etc.  working together leading to formation of heterogeneous team.  Heterogeneous teams are found to bring different perspective to the table and thus bringing creativity

Delivering Fast with right technical Debt – Forrester research upcoming Webinar details

  According to recent survey data by Forrester Research, Agile methods are now the predominant development approach. Their success is due to their promise of both delivery speed and business value. But agility is more than short term speed.
Short term speed can actually reduce long term business agility.

This reduction of agility is illustrated in the simple metaphor of “Technical Debt” which describes how short-term decisions that aid speedy delivery can, over time, end up drastically slowing down your ability to deliver value.

Agility means achieving the right balance between speed today and speed tomorrow.

Hear Dave West, principal analyst at Forrester Research discuss how organizations are striking the right balance between delivering fast yet keeping their Technical Debt down so that they can remain truly agile.

Dave will cover the following topics:

  

· The state of Agile development – drivers and current practices 
  

· The rise of Technical Debt
 

· The elements necessary to achieve the right balance between speed and Technical Debt
   

· A checklist for Agile success

Date: Thursday, January 27th
Time: 11AM EDT (5PM CET, 4PM GMT, 8AM PDT)
Please register for the webinar here: http://www.castsoftware.com/Worldwide/events/012711.aspx?gad=blogger

Agile estimation and Planning – Presentation

 

 

 

 

 

Recently Mike Cohn presented the summary of his book Agile estimation and planning during Las Vegas Conference.

 

 

 

 

The deck covers different types of estimation and levels of planning in detail with very good easy to remember examples.

The pictures in the slides speak thousand words.  One can download the deck from here

Poka Yoke – Mistake proof marketing

Definition of poka-yoke (as given in Wikipedia) is,  any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.   

Googling around on the benefits of Poka Yoke would throws up tons of results with astonishing numbers. People have reported nearly 98% increase in accuracy in their system , 0% error, 98% cost savings etc.

 

 

A very good introduction about Poka Yoke is available here. 

The popular methods in Mistake proofing include:

 

1. Contact Method
2. Fixed Value Method
3. Motion Step Method

You can get more details about each of the above methods here.

At the end of the day Poka Yoke is all about finding ways to stop mistakes or identify the mistakes before they occur.   Even though it was initially invented for the manufacturing industry, it is being applied to other industries like software too.

Some thoughts about applying Poka Yoke in Software development can be found here and here.  Automated software testing practices applied on Unit, Component and Integration testings are classic examples of Poka Yoke in software development.

Recently I came across this website where the author has offered some tips about  applying Poka Yoke for mistake proofing marketing.  One can also download free presentation about the concept on the same website.

This website is dedicated about Poka Yoke with wealth of materials about this concepts, certifications, etc. 

2 Minute Introduction to Lean and Kanban

Check this SlideShare presentation which gives a very simple and animated introduction about  lean and Kanban.

Attending the Java Oracle Open World 2010 Event

3 days of highly enriching sessions in Oracle Open World 2010 is keeping me occupied in San Francisco. Most of the sessions ending or beginning with Security, Scalability, Performance were sold out. It was tough to get seats for these sessions. Apart from attending Larry Ellison’s Keynote, I attended many sessions. I am listing a few of them here, and once I am back in India I am planning to blog about other sessions in detail on my architecture blog

1. Hadoop vs. Relational Database: Shout-out Between a Java Guy and a Database Guy.  This session focused on few tips around choosing Hadoop and when to choose RDBMS. Very interesting session

2. Mission Critical Enterprise Cloud Application

3. Journey to the center of Java Universe

4. Keeping your options open even if the cloud is not

5. More Best Practices for Large-Scale Websites: Lessons from eBay

 

 

and many more…

Nearly 41,000 developers from all over the world participated in this  event and as part of appreciation, Oracle had organized the Rock concert.  I enjoyed  listening to Don Henley and Black eyed Peas before heading back to the hotel late night.

How British Airways uses Agile

Here is a good article describing how British Airways IT department have started applying Agile methods and have started seeing a lot of benefits. 


Couple of points I liked in this this article include :

1. If you are interested in implementing Agile in your organization, start with a pilot project with a small team
2. Try to employ a coach to help you to begin the journey. They might be expensive but worth having them on board
3. Put people who are interested in Agile as part of initial pilot team rather than pessimists
4. Scale the Agile projects slowly to rest of the IT organization as opposed to scaling it quickly.

Scrum @ Home

Many scrummers have been implementing Scrum practices outside of Work but silently. 

My own example of

* Using  Information Radiators to track progress of tasks at home,
* Prioritizing the work,
* Retrospective with my family, etc.  

Recently I came across few blogs where Scrum practitioners are sharing info about applying Scrum practices outside work. 

Check them out here

*  Scrum For Kids
*  Scrum in Schools

You can also see few pictures of  how Saturday Chores could be handled in Sprints

. Don’t miss reading the details about how Sprint Planning was done, tasks picked by kids, etc just below the picture.

It is fun to see all this and at the same time good perspective of how Scrum can be applied outside work.

Are you getting any new ideas now to apply Scrum @ home ?

Google Wave, Innovation and Agile

The recent news that Google is officially shutting down “Wave” came as a shock.  Even though I never expected this to happen, I appreciate Google’s courage to shut down the product built with considerable amount of effort and money. This courage reminded me of the courage, one of the core values in Extreme Programming(XP).

 

Courage in XP is explained with as example as  :
Courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code

 

 

After re-reading the core values, I have been getting more questions than answers !
Do we really practice Courage in our projects ?  What fear do we have ?  Why do we hesitate to take risky decisions ? Who influences our decisions while we are on the project ? What do we need to change to practice courage ?

Coming back to topic of Google wave, the reaction to the Google Wave shutting down news has been pretty much mixed. Broadly the reactions were of 2 categories:

 

One really bashing Google for not thinking through  and finally shutting down the product

A

ppreciating Google’s courage and ability make quick decisions

I felt that these two reactions could be compared to Waterfall thinking and Agile thinking respectively.  The reason for this analogy is, Waterfall mentality is to force every one to think through all the possible things and create a plan engraved on stone. Agile being incremental and iterative in nature gathering constant feedback taking quick decisions every day. 

Even though waterfall way theoretically looks to work, it never does.  Agile thinking is all about quick action, getting the feedback and making course corrections, which I think Google did it as in the case of Google Wave.

Keeping the Google’s cue in mind, if one key value like courage is injected in Agile projects, then Agile teams will get an additional teeth to be more innovative. Without Courage, they would end up stuck with Waterfall thinking in the guise of Agile.

Agile Testing

I have come across many projects claiming to be Agile, however they are really doing nothing more than mini-waterfalls. They do the Requirements, design, coding and Testing incrementally and in a bi-weekly fashion. If you carefully observe, still testing is done during the last days of sprint/iteration.

What is not Agile Testing ?

Testing within Sprints in projects following Agile methods is not Agile testing. 

Developers have to do their own set of testing for “building the quality in” as per lean. However, the developer testing is not a replacement of traditional practice of testing. 

It is disheartening to note that, many people give a little or no value to the testing in Agile projects. According to me, Agile testing is important as a practice as Scrum Meeting or retrospective.

Myth around Agile Testing
There are still some myths around Agile testing.

* It is a myth that in Agile projects all the testing would be done by developers.  
*  Testers role would become obsolete in Agile projects

Additional factors that are given importance in Agile testing includes

 

1. Testers are no more reactive, they are proactive.
2. The testers are not in the project to identify defects but to build the quality in the product
3. Testers participate in all the activities of software development, right from Requirement analysis to design, architecture and till the end.
4. Testers play the role of Generalized Specialists taking one or two additional responsibilities  apart from testing. 
5. Test Automation is given importance than the manual testing

Agile Tester

With so many additional factors involved in Agile testing, is it really possible for traditional testers to switch gears quickly to accommodate the new changes ?    Answer is “NO”. 
It takes its own time and in the sense, it could take sometimes months. The rate of change depends on the support given by the management to the testing team.  More the support, smoother and quicker would be the change. 

 

 

Some of the mindset changes needed by Agile testers include
1. More stress on improving the communication skills
2. Courage to drive quality in by taking charge of projects
3. Proactive mentality rather than reactive
4. Eagerness to learn new technologies and framework to become generalized specialists.

In Summary:  Agile testing is all about change in mindset and focus on building the quality in the products.

Most Valuable Blogger

I have been awarded as the Most Valuable Blogger(MVB) by DZone. I am very excited about this news.

Emphasis on TDD in 1972

During the touring lecture in 1972, Edsger W. Dijkstra talked about the topic “The Humble Programmer”.  During this lecture he makes a statement, which I think is really revolutionary….

Those who want really reliable software will discover that they must find  means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging – they should not introduce bugs to start with.

Is he not talking about avoiding the wastes of Product development, one of the lean principles ?

Is he not talking about the Test Driven Development ?

 

Complete excepts from his lecture could be found here.

Even though such pointers to TDD has been propagated by thought leaders since 1970s, it is very sad to see hardly a few programmers follow this great practice even after 3 decades.

Science of Learning: My personal Experience

 

 

Recently  I read Mark Levison’s article Science of Learning:Best approaches for brain. He takes an example such as why many developers find it hard to grasp topics like Unit testing.
As trainers, coaches and mentors many people tend to use traditional way of  presentations(i.e. power point) to train people. However, these presentation ways of  coaching gets into short term memory.

In order to make an abstract idea stay in long term memory, several techniques are available. For example, making the training more visual, asking leading questions and sharing concrete examples that relate to what the audience already know.

In my Agile training programs, I have been already applying some of them concepts. For example, asking the trainees to think about solving the issues in their projects and then relating it back to Agile values and principles. 

Image courtesy : http://getfreeimage.com

Backlog Prioritization techniques

There are several ways to prioritize the requirements in the backlog. Some of the most popular ones include,

MoSCoW

                         
M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not effect anything else.
W - WON'T have this time but would like in the future.

Each requirement will have the priority which would be tagged to MSCW. “M” being the highest and “W” being the lowest.

This site gives a very good explanation about this technique.

Business Value Based

In this case, each requirement carries a business value it could potentially generate to the company. The business value would be decided either by the Product Owner or the Product owner team.

The requirement with highest business value is implemented during earlier releases .

Technology Risk Based

In this method, requirements are prioritized based on the risk associated in implementing it. The risk is typically based on the technology.

The requirement with highest technology risk is implemented during the earlier iterations.

Kano Model

In this method, the requirements are prioritized based on the customer preferences.

• 
  
• Attractive
• One-Dimensional
• One-Dimensional
• Must-Be
• Indifferent
• Reverse

You can read more details about this model here



Walking Skeleton

In this method, the requirements are selected such that minimal carefully selected end to end features are built within a short span of time.







Validated Learning

In this method, features are chosen based on the highest market risk i.e. some thing that is not experimented yet. Release it to the market, get the feedback and apply the learning onto the new feature.

This deck gives a good view about validated learning in the context of lean startup



mages acknowledgement: FreeDigitalPhotos.net

A few good quotes

  I have been reading

Agile Project Management: Creating Innovative Products (2nd Edition)  and in this book, Jim not only refers to a few good quotes by other authors but also has made many impactful statements.  The book provides views on Agile Leadership, Team Management and Agile Project Management. 

A few good quotes that I liked from the initial few chapters include

 

* Traditional managers view the plan as the goal, whereas agile leaders view customer value as the goal

*

Commanders know the objective;

leaders grasp the direction.

Commanders dictate;

leaders influence.

Controllers demand;

Collaborators facilitate.

Controllers micro-manage;

Collaborators encourage

* Leadership is what crosses the frontier between what we did yesterday and what we’ll do tomorrow. We’ll argue…that the real mark of a leader is confidence with uncertainty—the ability to admit to it and deal with it.”   - Phillip Hodgson and Randall White

* Agile project leaders help their team balance at the edge of chaos—some structure, but not too much; adequate documentation, but not too much; some up-front architecture work, but not too much. Finding these balance points is the “art” of agile leadership

Does it make sense to use MS Project in Agile Projects ?

 

 

 

 

 

 

 

It is a tradition to use MS Project as a Project Management tool in Waterfall projects. However, trying to use MS Project in an Agile project makes the lives of the developers more difficult than easy. 

There are several reasons for that and a few based on my personal experiences are..

1. Adding new tasks in between as they get discovered during the sprint causes havoc while using the tool

2. Tracking  story and task completion in the context of sprint is difficult
3. Moving around the incomplete stories and tasks to different Iteration makes the project plan chaotic
4. Picturing  Product and Sprint Backlogs while using MSProject is not so easy

In addition to above reasons, Michael Dubakov has written an article explaining why MS Project sucks in iterative development projects.

Rise and Fall of Waterfall Model

 

 

 

Craig Larman’s most popular book  Agile and Iterative Development a Manager’s guide  covers the topic about how Winston Royce’s white paper was misinterpreted which lead to the birth of Waterfall Model.

 

 

Incidentally an Agile practitioner has created a video explaining the birth and death of waterfall model in a humorous way.  The video is

available on YouTube

Balancing Organizational and Project Goals

In many outsourced(near shore or offshore) services organizations, employees are expected to take part in activities that are outside the purview of their projects. These activities are intended to support organizational growth in someway or the other. A few of such activities are

Conducting interviews for hiring new employees,
Taking team out for lunch/dinner,
Arranging an offsite meeting,
Conducting trainings, events
Publishing whitepapers, attending conferences, etc

The above mentioned activities need effort, and this effort needs to be accounted some where. Naturally, one might get few questions like:
Should one track these tasks in Sprint Backlog ?
Should one keep the customer updated about these tasks ?
Should this be estimated as part of Planning meeting ?

Being Agile practitioners, it is expected that the team should practice as much transparency as possible in estimation and tracking. Keeping this in mind, one should estimate the effort being spent on such activities during each iteration and capture it as part of a task in sprint backlog. This also ensures that the customer is aware of these non-billable activities at the same time, IEH and velocity counts are captured accurately.

It is not a good idea to mask these activities and also not informing the customers. This would not only affect the credibility of the team but also forces the team to stretch themselves to compensate for the lost time.

Image: djcodrin / FreeDigitalPhotos.net

Scrum Meeting – Punishment by collecting $ is it the right way ?

One of the first rules of Scrum Meeting is to ensure that it is conducted at the same time every day at the same place. It also expects that the team members should come on time to the Scrum Meeting.

Typical practice is that, late comers to the Scrum Meetings should either wear a joker cap or pay a $ as punishment for arriving late. However many thought leaders share that these practices of punishment is bad and it is not going to improve the situation or change the behavior of the late comers. Worse, Thought Leaders proficient in Intrinsic and Extrinsic Motivation, believe that, over a period of time the extrinsic motivators(reward or punishment) actually reduces the intrinsic motivation.

* So, what should we do in this situation ?
* How do we handle the late comers ?
* Should we ignore them ?
* How do we make the late comers for the Scrum meeting to come on time ?

The answer seems to be not easy. Researchers believe that there is no one formula that could be used to motivate every one. If some one is not coming on time to the Scrum meeting means either he/she is not interested or does not believe in these meetings and could be something else. One needs to identify the root cause of lack of intrinsic motivation and work on an individual basis rather than applying the same reward/punishment formula.

Cognitive Evaluation Theory and FLOW seem to provide some insights to improve the Intrinsic motivation.

Retrospectives in Agile Multi Site Development

Unlike other Agile practices, Retrospective sessions involves a lot of
emotions. Emotions could be easily understood(also handled) by looking at the body language of the people around us. However, in a distributed development projects, teams are scattered across various locations and this in turn makes it hard to understand the body language. This is one of the reasons why it takes more time for the scattered teams to bond with each other and thus reducing the efficacy.

Even though no tool or technique can replace the experience
emanating in a collocated team, there are a few that could

be practiced to improve the effectiveness of distributed retrospectives.

From the logistics perspective, one or more of following tools
could be used

Tool Name	Effectiveness
Voice chat through Wired phones, typically what is termed landlines or using popular tools like Skype, Yahoo Messengers, etc   without  Web cams	Low
GoogleDocs, Wikis in addition to voice chat and no web cams. Download the GoogleDocs Retrospective template from here	Low
Web cameras connected to tools like Skype or Office Communicators in addition to use of Google docs, Wikis,etc	Medium
http://www.CardMeeting.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.Dabbleboards.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.IdeaBoardz.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.IdeaScale.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.mindmeister.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.etherpad.com Using this in addition to voice/video tools increases effectiveness	Medium
http://en.linoit.com Using this in addition to voice/video tools increases effectiveness	Medium
Telepresence and Video Conferencing kind of tools  in addition to one or more of above mentioned tools	High

 

Note: Some of the above mentioned online tools could also be used for other Agile practices like Requirement gathering, brain storming, design discussions in distributed mode.

 

Patterns

Two popular patterns of distributed retrospectives include
1. All hands Retrospective
2. Location Specific Retrospective

In case of All hands Retrospective, all teams participate together
using one or more of above logistics. This pattern works well if teams
are located in same or closer time zones. May not be a good idea to apply this for larger teams . 

Location Specific Retrospective, In this pattern, location specific
teams conduct retrospectives and then the leads from each of these
location conduct “Retrospective of retrospectives” synching
Sad/Mad/Glad data. Larger teams (>15) can apply this pattern.

Test Driven Development for Embedded C++ Programmers

 

Src:blog.briandicroce.com/2008/03/

A lot of articles are available explaining TDD for Java and .NET. However I rarely find “good” TDD articles for C++ and C. 

James Grenning explains TDD for embedded C++ programmers in a step by step approach in this article

Comparison of Heavy and Lightweight methodologies

 

Several articles have been written comparing the heavyweight and the lightweight methods. 

However, I found this document to be very comprehensive in comparison.

 

 

The document compares the Heavy Weight methods like
Waterfall, UP and Spiral Model  with the Light weight methods like

  XP, Scrum, FDD, DFDM,etc.