Archive for the Collaboration Category

Good Enough Software Does Not Mean Bad Software

Posted in Agile, Business Value, Collaboration on December 17, 2009 by vikramadhiman

Software to be released should be just “good enough” and not perfect. You hear that a lot these days. “Good enough” from whose perspective? From the perspective of people who release software or from the perspective of the people who will use software? If it is latter, then who decides what comprises “good enough”?

The thought for this post came from one of people I follow on Twitter @enkerli. In the time I have known Alexandre, I have found him to be extremely patient [he is a teacher of repute and of some experience too]. Yesterday, he tweeted -> “enjoys draft æsthetics yet wishes more developers would release stable products. / adopte certains produits trop rapidement.” You can not but realize that he must have signed up for some web application [we will be using web application scenario in this post] expecting the best, only to be let down by an application where either things are either not there or just do not work. Personally, this happens a lot. I type out the web address of this supposedly great web application after reading a review, blog post, news article – and immediately see tonnes of HTML issues – inconsistent fonts, links not linked [with a # key that seems a favorite of development teams these days], pages that are under construction [with no dates of when you expect these to be working], server bandwidth issues [with web applications unable to handle a few thousand users], forms that won’t submit no matter what you do, pages that go haywire when error messages appear at the top and emails that confuse you further. It is almost as if the teams are not asking if it is “good enough” but even if it is “bad enough”, we can always claim that this is “good enough” for now, more is coming later.

I understand the rush of releasing now than tomorrow, why teams would want to adopt this. If you see lot of people using your application, you know the major risk “Are we building the right thing the right way” is minimized. Further, if the major feedback is on product direction [what the heck is this, abandonment rates are high, XYZ do this better], it is nice to be able to figure out these issues sooner than later. There are multiple ways of checking that [for instance focus group meetings, stakeholder meetings, exclusive previews and private beta]. Probably, like all things that mean no harm, “good enough” is being used by people in a way that suits them. Hence, it is important to understand what exactly “good enough” means. One of the good definitions of “good enough” can be found here. It is more a measure of software quality [and code] – simple, correctness, consistency and completeness. Another good definition can be found here: good enough software is the best software we can write given all the external constraints (money, time, resources, inadequate information, etc) placed on us. It’s certainly not the best software we can write before we clock out to go see our son’s ball game or the best software we can write because we don’t understand the problem space and can’t be bothered to ask. James Bach of Satisfice Inc. describes “good enough” software as making rational choices in the face of market-driven projects. The idea is that it’s okay to ship with bugs as long as you ship with the “right” bugs; that, given enough benefits, the minor problems will be overlooked. You have to be able to distinguish between important and unimportant, necessary and unnecessary. According to Pete McBreen, “The decision to ship is based on the risk of shipping a software product that will be seen as low quality. Once that risk is low enough for the organization, the software is good enough to ship. Conversely, if there are not enough valuable features in the software, even if the defect count is zero, the risk of shipping is too high and the software is not good enough.”

Now, that we saw that “good enough” is not a cosmetic 2 minute pop philosophy concept – the next argument would be “it takes time to write such a software”. Yes, it does. All software needs time to think and write. How much – depends on competence of the people. Like most things Agile, it takes maturity and courage to accept shortcomings to write software that is “good enough” – in a true sense.

Who can become a Product Owner?

Posted in Agile, Collaboration on October 14, 2009 by vikramadhiman

Who is qualified to become a Scrum Master or Who can play the role of Scrum Master, is one of the most frequently asked questions in the Agile community. I believe the more important question and often the one that does not get asked is, Who can become a Product Owner? Why is this question more important? It is because, what you are building (and why you are building this) is often more important that when are you building and how are you building it. The last two questions are important but only after the first two. The first two questions also help frame the vision for the product as well as:

1. Chronologically, Product Owner role starts before any other role in an Agile or Scrum team.

2. Depending on what is your vision for the product, you could outsource a part of whole of it right at start or at a later date.

3. You build the product to achieve a particular purpose. The person responsible for the same is the Product Owner.

If this is such an important question [and correspondingly role], then what are the qualifications one should look for when selecting a Product Owner? I have been a Business Analyst and Product Manager. I have interacted with many Product Owners too. There has been an interesting discussion on who can be a product owner on the Scrum Development Yahoo Group recently too. Based on the feedback collected from all these sources, I have compiled a list of who would make an ideal Product Owner:

1. Product Owner is a part of the team and should hence be available as much as possible to the team [close to 100%]. Hence, PO can only be someone who is available to the team 100% of the time.

2. Product Owner needs to understand the big picture – the philosophical as well as practical aspects of what is being built. This would often require excellent domain knowledge.

3. Product Owner should know what will work – hence, exposure to marketing and sales is important. This is also often called Voice of the Customer. Basically, Product Owner should deeply empathize with customers – their needs, their frustrations and their wishes.

4. Finally, any exposure to technology – programming, UI, QA is an additional bonus [in most cases a required bonus].

The next question is which of these is the most important requirements? I think all 04 and in given order of priority.

One additional requirement, which I believe all people should possess and so should Product Owners and Managers : People Management and Interaction.

A Sprint Retrospective – The Ideal way to Start Agile

Posted in Agile, Collaboration, Retrospectives, SCRUM on September 17, 2009 by vikramadhiman

Is the Certified Scrum Master class I attended about 03 years back – Pete Deemer, the Guru who led Yahoo’s adoption of Scrum in multiple locations, said “Even if you did not do anything else but only Sprint Retrospective, you will see tremendous improvements in your process or way of working.” That is, even if you were not doing any of Sprint Planning, Sprint Backlogging, Product Backlogging, Sprint Reviewing or even Daily Stand Upping, you would be doing very well, by doing just one practice – Regular Sprint Retospecting. That is definitely a tall claim. And from my experience in the last 03 years, a true one too.

Let us look at the basics first. What is a Sprint Retrospective? Rather, what is a Retrospective? As per Wikipedia, Retrospective (from Latin retrospectare, “look back”) generally means to take a look back at events that already have taken place. For example, the term is used in medicine, describing a look back at a patient’s medical history or lifestyle. It is particularly useful to look at the medicine analogy here. Retrospective, in medicine, means looking back at medical history.  In Software Development, a retrospective means looking back at project history. This is typically, with a team and depending on the context it could include project managers, senior managers, directors, VP’s, whole team, testers, developers, business analysts in any combination. Extending the analogy with medicine further->typically, you will look at the medical history only if something has gone wrong or when the person has died [and you are doing an autopsy]. Unfortunately, most retrospectives in Software Development are also held, when something has gone wrong or at the end of a project. Agile Software Development uses retrospectives, like regular diagnosis [and not just when something bad happens]. After every iteration or sprint, the team gets together to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects.

Agile and Scrum are adaptive processes.Retrospectives and Daily Stand Ups are too practices which enable inspection as well as introspection – both necessary for adaptivity. Even if the team did not do a product backlog or sprint backlog or burndown chart and the team just did regular Sprint Retrospective, what will it unearth? One of the first things, they would probably identify is that we never knew where we are and what everyone is doing or where someone is stuck. They will come up with burndown charts [or some variant/ substitute] as well as more regular meetings [daily stand ups]. More features like sprint planning, sprint reviews, product backlogs etc. could come up. Some things like no change during the sprint could never come up. Hence, the team could come up with their own version of Agile – something that fits them the best.

The above paragraph assumes some critical things:

  • The team is empowered and capable to drive a retrospective as well as implement the action plans that are highlighted for the next iterations. Significant management as well as team buy-in for being process leaders rather than process followers is hence, required.
  • Given the nature of retrospectives, they can degrade from looking back to blame games quickly. Hence, good facilitation and guidance during a retrospective is required.

Some retrospectives can be more productive than others. We will take a look at more on retrospectives in the future articles. You might also be interested in the Start, Stop, Continue Technique of Agile Retrospectives.

Scaling Product Owner Role in Scrum : Potential Issues and Workarounds

Posted in Agile, Collaboration, Project Backlog, SCRUM with tags , , , , , on February 23, 2009 by vikramadhiman

In the previous post on “Multiple Product Owners or Not“, I analyzed if there is a case for multiple product owners. As per me, there can be grounds and case where this is a necessity. Now let’s see if we did indeed have 02 product owners, what will happen. The potential problems [I have seen these] could be:

  • Product owners have power – they influence the product direction. As long as 02 or more product owners agree on the direction, it is fine. However, product owners also influence product execution [user interface, test cases, priority]. These are soft areas and different people can interpret these differently.
  • Each product owner is likely to have more appreciation for their own features and their importance, than of the other product owner. If both of them feed a common development team, there would be issues of working together at some stage or the other.
  • If you have product owner depending on expertise [horizontal slices than vertical slices], there will be even more potential for disaster striking soon. Let’s take an example. Something which is good from SEO perspective, might not be so great from user interface perspective. If we have 02 product owners, one for SEO and one for user interface, major conflicts will arise.
  • Having a whole lot of people influence product direction can mean paralysis in decision making, where almost the bare minimum everyone can agree on, only gets done and anything exciting and challenging, will never even be attempted.

There are some things one can try, to make multiple product owners work together. Let’s look at some possible solutions:

  • One way to work around this is to have all the members of the team as stakeholders, but have a Chief Product Owner to have the final responsibility of prioritization. Hence, depending on the size and nature of your product, one might have group of people responsible for grooming the product backlog [design, SEO, user acquisition, interface, development, marketing] but only one person should be responsible for overall prioritization as well as decision making in case of conflict. The problem in this case is to identify such a person. Typically, such a person would be someone with great knowledge about the product, marketing and strategic objectives. This is the typical approach and this takes along specialists in various domains together. Although, this is against the idea of generalists not specialists, it is needed. I personally believe specialists have their place and very important one too. I have benefited as a Product Manager from people advising me on aspects I will overlook or most likely not even know. Specialists give me insight from marketing perspective – Internet Marketing (paid), Internet Marketing (organic), Offline Marketing Channels, User Behavior … one which [A] I won’t ever get time to analyze in detail or [B] would need enormous training to even get started.
  • Another approach is to divide the product in multiple sub-products. The Chief Product Owner can divide work to other Product Owners depending on their expertise, experience and importance of the features. This is commonly called feature teams. Organizations and products which spend time on this, reap benefits. We are getting started on this and this is streamlining our processes. There will always be areas where the Chief Product Owner would step in, but mostly delegation and scalability of product owner roles is supported through this model.

One Product Owner Only or More Than One?

Posted in Agile, Collaboration, Project Backlog with tags , , , , on February 21, 2009 by vikramadhiman

Once every few months, debate on “Whether there is a case for multiple product owners” comes back in Scrum and Agile Community. Most often, the response by Scrum Community is – No. There should be only one product owner and there CAN NOT BE more than one product owner. There are some [like me], who suggest that after the very first releases out, the product becomes too big and complex and multiple directions emerge and one person does not have full knowledge or expertise or even time to be able to do the job of a product owner effectively.

Let’s start by looking at the role of a product owner. Product owner is the main decision maker on behalf of the stakeholders, users, customers and clients. Product owner decides what is to be built and when. Product owner is not the only contact but most likely the primary contact for the team. If the team has only 01 product owner, it should theoretically move faster. One person would make faster decisions and team will get used to working with one person after a few sprints, fostering increased collaboration and more agility. This works fine if the product owner is available and qualified to make these decisions. However, this might not always be the case. As the product grows, there would be multiple directions, sub-products and large development teams. One product owner might just not be qualified or even available to take the product further. Hence, if 01 product owner is the bottleneck [does not have time, does not have competence], adding a product owner might be a good or only option. This is not always smooth and not without its problems. However, this is the only option available. And like scaling development teams and Scrum Master role, Product Owner Role also needs to be scaled.

The main argument against why there should not be multiple product owners, is that in Scrum, Product Owner is the single wringable neck. So, once you have more product owners, you won’t know whose neck(s) to wring? This according to me is a no starter argument in the first place. I have never understood the concept of single wringable neck at all. How can one person be so powerful as to be responsible for the overall success of the product? Product Owner trusts various people to give the right input. Product Owners listen to various people who give their own input and then prioritize features. Success or failure of these features [some of which can take time to reflect], are dependent on the advice. It is a collaborative, snyergestic relationship between domain heads and product owner. Both are in it together, and not separate. Further, the idea of single wringable neck goes against the ideals of Agile as well. What is the use of wringing someone’s neck after product fails? Why not start with “Everyone did everything in their power to make the product successful” thinking to the product owner as well? And, most importantly, can “we need 01 single wringable neck” potentially overpower a solution that can work [and works] of scaling the product owner role further?

In my next post : Scaling Product Owner Role in Scrum : Potential Issues and Workarounds

Agile Christmas Greeting

Posted in Agile, Collaboration with tags , , , , , , on December 25, 2008 by vikramadhiman

Seasons Greetings !!! May this season and new year bring you:

  • closer to your team,
  • patience to understand,
  • reflection to hold reactions 
AND
  • lots of togetherness, bonding and fun at workplace
Hope you are a harbinger of “we” and “us” and help make your team and organization a better place.

Jeff Sutherland – Scrum and Agile Lessons from Google

Posted in Collaboration, SCRUM with tags , on November 21, 2008 by vikramadhiman

I came across this great video from Jeff. I think everyone would enjoy this one greatly. Scrum was incrementally introduced at Google, so the engineers discovered themselves what was not going as well as they thought. The main practices like big charts, daily stand ups and retrospectives are implemented with vigor. Some teams also couple XP engineering practices with Scrum and this makes it even better.

Follow

Get every new post delivered to your Inbox.