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.


Agile India 2010 – Mumbai [Jan 16-17] and Bengaluru [Jan 22-23]

Posted in Agile, Public Speaking on December 7, 2009 by vikramadhiman

Agile India, is organizing Agile India 2010 Conference in 2010.  It is the first two day conference from Agile India and would be held back to back [consecutive weekends] as below:

Mumbai, Jan 16-17 at Narsee Monjee Institute of Management Studies

Bengaluru, Jan 22-23 at Symphony Services

You can find more information at the Agile India 2010 Conference Page [more information coming soon, but if you are interested to speak at the Conference then see here :]. The conference tentative schedule would be up soon.

Product Vision : The Key Role and Responsibility of Product Owner

Posted in Agile, Business Value with tags , , , , on October 19, 2009 by vikramadhiman

Continuing with the discussion on Product Owner role and responsibilities, and based on two excellent comments from Martizza and SJJH, let us review the key role and responsibility of the Product Owner. One can argue that the four skills/ competence areas highlighted in the Who can become a Product Owner post along with people management and interaction skills, help the Product Owner articulate, defend and refine the Product Vision. One can also argue that this is a separate skill and competence area and some people can just be better at this job even if they do not have the domain knowledge, are not technically sound or have the necessary experience. What will these people then typically possess? I think it would be a mixture of ability to learn [learn very fast], a highly analytical mind [capable of drawing analogies], intuition [strong emotional connect with real and abstract] and a thinking mind [one that can think even when it does not know it is thinking]. These people would generally believe hopelessely in what they are working on – and it is this belief and the conviction that helps them exude the product vision. Hence, when one is looking to appoint or hire someone for Product Owner position, one should see if they identify with the product and what are the ideas they bring to the table. If the connect is established, the rest of the work would flow a lot better.

So, what exactly does a Product Owner do with the Product Vision. They do 03 things:

1. Define the Product Vision – This involves close connect with the customers and market needs. Hence, domain expertise and exposure to tech support/ marketing comes in handy. Further, exposure to some sort of modeling methods helps the Product Owner define the product vision. Often, the Product Vision phase can take long. As a Product Owner, you may consult other domain experts, technical team or embark on marketing feasibility studies to confirm and reconfirm the vision.

2. Articulate the Product Vision – This is more important than 1. Typically, the Product Owner should be available to the development team anytime and everytime. The Product Owner should be able to sit down with different team members – together, in groups or alone – and discuss aspects related to the product – what will happen in 02 years, 02 months and what do they think could happen. This helps build the trust and orients the developers from a Product Owners perspective – a key requirement to build a great product. One of the means available with the Product Owner, to articulate the Product Vision is Product Backlog and ceremonies like Sprint Planning, Sprint Review help achieve this too.

3. Refine the Product Vision – Each time the Product Owner meets people from marketing, sales, technical support, development team, testing team or customers – they will keep uncovering new things about the product. It could just be new technology [Google Wave was launched a few days back for instance] or a new trend [micro-blogging and social media]. This can represent opportunities or threats. Product Vision is not stagnant. It is dynamic.

If a Product Owner can take care of the Product Vision, the Product would largely take care by itself.

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.

Why does the Product Owner (PO) Disturb the Team?

Posted in Agile, Release Planning on September 2, 2009 by vikramadhiman

In Agile and Scrum talks or training, Product Owners (PO’s) or people playing the PO role in projects/ products, ask : Is it alright to ask the team how is it going during a sprint?

A good team would probably direct him/ her to the burndown chart or the Kanban inspired to-do lists. duly sorted in in-progress, to be picked up or done. The teams who do not maintain the burndown chart only have themselves to blame for the Product Owner or Product Manager, asking the obvious. Now, let us say the team maintain the burndown chart and the PO can see it, what if he/ she asks – Is this your best pace or Could you do better or I don’t think this is good enough? This is probably getting into a territory, where there is no yes or no – it is just something you have to analyze context wise. Let us analyze some of the reasons [assuming that the team is maintaining correct working pace and is not padding up or slacking]:

  1. Why the Product Owner could say such a thing? The Product Owner obviously does not trust the team.
  2. Why does the Product Owner not trust the team? Probably the PO has no clue what all we do.
  3. Why does the Product Owner not have this clue? Because he can’t see it.
  4. Why can’t he see it? Because we did not put it on the sprint backlog or to-do list.
  5. Why did we not put it? Because [A] We were lazy [B] All programmers and testers know what all it involves [C] It won’t make sense to business [D] It takes time

Other than [D] above, none of the above seems like compelling reasons for not listing all the tasks. Also, the consequences of not putting it because of [D] -> lack of trust in product management and development – is too big to account for extra minutes it takes to list all tasks and dependencies.

Hence, next time the PO has this urge to ask you>>please just ask yourself the 5 questions above and see if you can find a solution. If your PO asks you to change something/ do an extra thing/ tweak something>>then Scrum is pretty clear on how you should handle it 🙂

A Practical Guide to Distributed Scrum – Review the Upcoming Book

Posted in Agile, SCRUM with tags , on August 25, 2009 by vikramadhiman

Distributed Scrum/ Agile teams is one area where most globally distributed teams struggle. There are issues of time zones, cultural nuances and languages apart from other local issues. However, globalization of work and workforce is a 21st century requirement and reality. Implementing Agile brings these differences and issues out in the open even more. A Practical Guide to Distributed Scrum – the Book hopes to provide people implementing Scrum or Agile in a distributed environment with some examples and experience insights. This book has been developed through the collaboration of the IBM Scrum Community [comprising more than 1000 members across 07 business units of IBM in 30 countries]. The book specifically will take a look at these aspects:

  • Estimate user stories and work with the Product Owner as a distributed team
  • Implement techniques to more efficiently engage in Release and Sprint planning
  • Effectively conduct daily Scrum meetings
  • Enhance communications between team members throughout the Sprint
  • Conduct a productive reflection to improve productivity and quality over the next Sprint
  • Demonstrate progress to stakeholders at the end of each Sprint
  • Leverage tools to improve the productivity of distributed teams

The book is written by:

Elizabeth Woodward who is a Senior Software Consultant with IBM Quality Software Engineering under the office of Innovation and Technology.

Dr. Matthew Ganis is an IBM STSM and site architect. Matt is the co-creator of the Agile@IBM community and was an early adopter of agile within IBM.

Steffan Surdek is a User Experience Lead and Agile Champion in IBM.

You can help review the early drafts of the book at Distributed Scrum website.