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.
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.
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?
A couple of weeks ago, I was doing an evaluation of the many Agile Lifecycle management tools in the market for a customer of mine. I was pleasantly surprised to see the various options that an organization would have when they are looking for one.
Before we go further, let us define it. An Agile Lifecycle Management (ALM) tool is one which helps to manage your company’s Agile product development by providing a way to manage requirements, day to day work and progress reporting.
The first question that first comes to mind is “Do we need a tool to manage Agile product development?”
Well, if your team, your product owner and other interested stakeholders are co-located, there definitely is no need for an Agile Lifecycle management tool. A whiteboard, sticky notes, a chart paper for the burndown and a dedicated scrum master who keeps all this in good condition is sufficient enough. However, in today’s corporate world, the distributed product development scenario is one where a team, its product owner, other stakeholders and sometimes the Scrum Master are spread in different geographical locations across the world. For all such distributed product development environments, there definitely is a need for an ALM tool. Continue reading →
On Dec 9, 1914, Thomas Alva Edison‘s manufacturing unit was razed by a major fire destroying much of his work. When asked, he said “I am 67, but I am not too old to make a fresh start”. Not as serious as Edison’s situation, but I feel that the “Fresh Start” situation is very evident when a Product Manager moves to a new company / new domain, or when a person moves to a new city or country in search of a job.
The people are new, the environment feels hostile and cultural practices are different. The previous good will and clout that you held no longer apply here. The best part is that your mistakes from the previous place are not there too. It is a reboot of sorts. You can start afresh. It is the perfect time to shrug off some old practices that you were not happy with earlier. Since you do not have much of a reputation or a baggage, you have enough liberty to experiment with yourself. Continue reading →
As organizations make their movement from Waterfall to Agile software development, a shift in culture takes place. One discipline that is most affected in this whole change is Product Management. They have to cope up with the demand for more releases within the same time and each release has to have meaningful content.
I have tried to list the traits needed for a successful Agile Product Manager here. Continue reading →
Jack’s organization launched a path breaking web based Application a couple of years ago, which took the market by storm, got in many new customers, filled up the coffers and made investors proud.
Over the years, the Product Manager moved on, some people in the Product development team were moved to other products, and few quit. To make matters worse, the demands from customers for enhancements and bug fixes kept coming in, the client environments evolved and the competition more or less caught up. Continue reading →
We have had views from Abhay Mathur on ‘When did I last meet my customer‘. Once the Product Manager has ensured that he has chanted the above mantra enough times and has a fair understanding of the customer’s pulse, it is imperative that he translates his understanding to a language that the Product delivery team best understands. So, it is time for the mantra “when did I meet my product development team last”?
These are some of the questions that the Product Manager has to periodically ask himself and the team: Continue reading →