Author Archives: Sampath Prahalad

About Sampath Prahalad

Agile and Scrum practitioner and evangelist. Certified Scrum master and among the first 50 PMI-Agile Certified Professionals in India. My firm belief is that each of us have something to share and teach which makes us a Guru. So, ScrumGuru refers to each of us who mutually exchange ideas and thoughts thus making it mutually enriching.

The Silent Achiever

Leave a reply

Here is a good article about the 7 Must Have Project Management skills. I really liked the way that it is laid out and I believe that these skills are Must Haves for a successful Project Manager. However, the skill No. 6 “Recognize and solve problems quickly” rang a bell. I do agree that a Project Manager should be able to see and resolve a problem quickly. However, what I think is a better skill to have is the ability to predict a particular problem or risk before it happens, work on it pro-actively and nip the problem in the bud.

The difference here is between a Hero and a Silent Achiever. Imagine two adjacent fields with dry grass and bushes on a hot summer day. On one, there is a fire caused by the extreme heat while on the other field, there isn’t. A Hero might be seen as one who goes in a helicopter, stoops low and douses the bush fire that is raging. The Silent Achiever is one who realized that the atmosphere is dry and hot, predicted the bush fire and cut the grass or sprinkled enough water on the field to ensure that the bush fire does not occur. So, for the casual observer, it seems to be Business as usual and the effort put in by the Silent Achiever is not usually noticed. Continue reading →

Technology: Aids the experience or robs you of it?

Leave a reply

Technology aids you and it sometimes overwhelms you. But, have you faced a situation where it robbed you of an experience?? Here is my case in point.

The use of a Digital camera: Helps me to capture moments that can be re-lived many times in later days. I have looked back at pics of family and friends that I took years ago and felt nostalgic about the moments. I am a keen photo enthusiast and love to use a digital camera whenever possible. However, I have at times felt that it has robbed me of experiencing an event as it happens. I recently went to the Sea World at San Antonio where the famous Shamu whale show is held. Me and my 6 year old kid were very excited at the beginning of the show. However, I had thrust upon myself the additional responsibility of capturing pics of the killer whales in action using a digital camera. What happened over the next 20 mins is something that most digital camera users would have experienced. My kid completely enjoyed the experience where the whales were performing various acrobatics and jumping in and out of the water with great precision. Me, on the other hand was trying hard to predict the whale’s next move, pinpoint the exact location of the move in the big pool and point my camera at the right place. And I was usually wrong.. So, by the time I turned around and pointed the camera and clicked, the whale was done with its flawless acrobatic movement and was back in the water. What I was left with was a picture of the turbulence in the water. See some pics below.

ShamuShow2ShamuShow3

Continue reading →

Documentation updates in Agile Projects

2 Replies

Scrum and other flavors of Agile expect a potentially shippable product at the end of each Iteration or Sprint. This typically means that each user story within the Sprint has to be developed, integrated, tested, documented and made deployable to production. While this is not new, I have seen many variations to this in my experience with Agile teams. I am going to deal now only with the Release documentation part here. Everything else is out of scope for now.

Consider the scenario below.
In a reasonably small organization, we have the Product Marketing manager Laura who doubles up as Product manager of a desktop application GoldSpot that back-ends with a database server. Laura is responsible for pretty much everything on GoldSpot. She is always seen juggling and shuffling between business case evaluation, wire-framing, product backlog creation and constant prioritization, user acceptance testing, creation and updates to user and admin documentation, customer demos, marketing communication, etc. The product development team consists of 3 developers, 2 test engineers and a Scrum master. The team and Laura meet over Skype for the Sprint planning meeting, the daily standups, Sprint review and retrospectives. The team is in their third Sprint, have just created a prototype worth showing to customers and have 3 more Sprints to go in this Release.
Wanting to adhere to the practices of Scrum, the Scrum master asks Laura to update the User and Admin guides as part of each user story and each Sprint. However, Laura who is severely short of time, finds this to be an overhead to her. Here is her stance. “The product GoldSpot is atleast 3 Sprints away from the Beta Release and has a good amount of functionality and UI changes going in between now and then. If I make updates to the Beta documentation (User guide, Admin guide) in each Sprint, I will definitely have to revisit it in the coming Sprints and over write them when the UI or functionality changes. Also, I am the person who is providing demos to customers and know each feature well. I am showing GoldSpot to customers but not distributing it to them right now. In my backlog of tasks to do, I definitely feel that updating the guides is low priority and something that will move to the top of the list in the final Sprint or the one before that. This is like the customer communication or the training that we do when we get close to the Beta Release.”
I definitely feel that Laura has a point and while Scrum advocates a potentially shippable product at the end of each Sprint, it does not really go into the specifics of what makes the product potentially shippable. I have seen this model work well for Scrum teams where the Release documentation is written by the Product Manager or by a Technical Writer who is spread thin across different products.

Is it then time to take the “Release documentation update” activity out of the Sprint’s Definition of done? Or should we persist on getting it done in each Sprint?

Let me know what you think.