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"

Agile and Model of Concurrent Perception

Dr. Rubinstein is professor of engineering and applied science at the University of California, Los Angeles, has written articles and books on Concepts in Problem Solving and Tools for Thinking and Problem Solving.

As per Dr.Rubinstein's model of concurrent perception, if we start with trying to keep the order from the beginning it leads to Chaos at the end.

For example, in traditional waterfall model, the stakeholders try from the beginning to keep order by

• trying to gather all the requirements and freezing them
• creating project plan written on stone with exact dates of release and delivery
• building the design and architecture and freezing them

Since there is no room for a retrospection at any time in between, the traditional waterfall model leads to chaos at the end with the delivery of the poor quality product, missed deadlines.

Dr.Rubinstein, suggests that try to have chaos as much as possible in the system. Chaos here, does not mean a havoc/uncontrolled nature, but a sense of openness to receive feedback.

Dr.Rubinstein quotes the example of car manufacturing. Before building a new concept car, engineers from various departments are invited for a discussion and their views are taken. At regular intervals, feedback from respective departments are taken, even if it leads to many changes to the design. The system which is open for changes in the beginning, ultimately ends with Order.

If we look at the recommendation from the above model, i.e. have chaos to have order , don't you think this is where the principles of Agile fits in ? .

In case of Agile, the chaos stays in the system by virtue of practices like

• Open to receive new requirements at any time
  
• Collaboration with the customer on a daily basis and open to receive feedback
• Self Organizing and Self Managing teams as opposed to command and control
• Weekly review and demo for the customer to get feedback
• Retrospectives at the end of iterations to learn from past mistakes and plan for the future
  

Dr.Rubinstein says

concurrent perception feeds vitality, while sequential perception saps it

Agile Project Management Tools

During the early days, while Agile methods popularity was still at infancy, there were hardly one or two project management tools that catered to the needs of Agilists. Nowadays, I hear atleast a new tool almost every other week. I thought let me list them out here.


The following list has both Open source/freeware and commercial tools and the listing is not in any particular order.


1. Rally
2. VersionOne
3. XPlanner
4. Extreme Planner (Don't get confused with XPlanner mentioned above)
5. Mingle from thoughtworks
6. TargetProcess

OpenLogic in turn has done a nice work of comparing the following(7 through 10) 4 open source Agile PM tools
7. AgileFant
8. IceScrum
9. Agilo
10. eXplainPMT
11. SilverCatalyst
12. GreenHopper with JIRA
13. Agilebuddy
14. WoodRanchTech
15. PivotalTracker
16. BrightGreenProjects

17. XPlanner+ (Thanks Sezam20 for referring this tool)

Additional Information
You can also get additional details for some of the above tools from here.
Mike Cohn maintains the list of Agile PM tools here . (Thanks Phil for sharing the link)


Feel free to share the names of any other Agile PM tools that you might have come across and is not present in the above list.