Archive for Agile

Has the Agile World moved on?

Posted in Uncategorized with tags , , , , on September 19, 2013 by vikramadhiman

Tough question. As I write my first post on this blog after a long long time, I wonder if the world has actually moved on? The misinterpretations, myths and downright abuse is rampant and the bright spots few and far. I teach, guide and coach young and experienced teams. Because of my work, I also get the opportunity to meet some really bright software professionals – some who have considerable experience with software engineering processes, including Agile. Some recent conversations in some of India’s (and world’s) top companies around agile practices were like this.


  • It means too much pressure.
  • It means micromanagement.
  • Our company is too unique for this.
  • Are testers going to be out of the job?
  • Does it really work?


  • Our product management sucks.
  • Why are we forced to enter details in an electronic system?
  • It is not as cool as it is made out to be.
  • How do you get anything done really?
  • Does it really work?


  • Agile is not the answer.
  • Processes need to be customized.
  • You need the help of a software coach.
  • Process without engineering excellence does not work.
  • It depends.

That’s how it is now. That’s how it was years ago. Agile is now talked about by more people and in more countries but the rise has not been exponential. Is this because Agile has still to figure out challenges like scaling (SAFe and others are trying), real-time support (Kanban) and aligning the organization (Lean)? Or because, Agile starts as a destination but ends up becoming a journey, sometimes tedious and many a times, one with cross roads that take a while to figure out. Or maybe, I am not exposed enough. It is exciting to resume writing again.

Product Manager 2.0 – New Course I am Working On

Posted in Uncategorized with tags , , , , on August 1, 2010 by vikramadhiman

I currently work as a Product Manager. My last job was a Product Manager. The one previous to that was a mix of Project Management and Business Analysis. I have been an Agile and Scrum fan for a very long time now 🙂

One area where enough coaching is not available is the role of Product Manager/ Product Owners in Scrum and Agile world. I am compiling a slide deck talking about this. I’ll also think of exercises, theory and examples.

Whatever conference comes up next, I’ll try and schedule this talk there!

Any links, examples – will help!


Here is what the outline looks like:

  • What is changing about the way products are developed? -> Internet times, Marketing changes, Hardware upgrades, Customer preferences, Increased competition
  • What is changing about the way products are supported and marketed? -> Social communities on the web, Instant gratification, Thought leadership
  • What is changing about the engineering teams? -> More involvement in product strategy and support, Better work-life balance, Increased communication demands, More informal structures
  • A bit about Agile and Scrum
  • What does a traditional Product Manager do?
  • What changes now?
  • How to gather requirements?
  • How to write requirements?
  • How to prioritize?
  • How to work with engineering teams and testers?
  • How to work with marketing, support, sales, PR?
  • How to work with senior management?
  • Skills required!

This is still a bit hazy. Let’s see how it develops 🙂

How to Prioritize Requirements YouTube Video

Posted in Agile, Business Value, Project Backlog, Release Planning with tags , , , on July 24, 2010 by vikramadhiman

I have written about how to prioritize before:

As Agile Product Managers, you are constantly prioritizing requirements to get higher value items out sooner. One approach I saw recently, seems very promising. Here is the video. Go ahead and watch it.

Basically, divide your requirements into four quadrants with Y-axis being Business Value and X-axis being Complexity. Hence, you would ideally do quadrant number 1 first and quadrant number 4 last. You can take a call between quadrant number 2 and quadrant number 3 – depending on what your current business strategy/ pull is. Simple. Do it over and over again and we will always provide higher value first.

Team Leads or Project Managers as Scrum Masters

Posted in Agile, Change, Project Backlog, SCRUM with tags , , , on July 22, 2010 by vikramadhiman

In organization after organization, transitioning to Scrum, you see one common pattern. The pattern has existed for at least 03 years now. The pattern is seen in all organizations [at least in India] – established big names as well as upcoming talked about/ blogged about startups. There is a team and there is a Product Owner [or Manager]. So far so good. There is also a Scrum Master – who is also the Project Manager/ Development Manager/ QA Manager/ Program Manager/ Project Lead/ Team Lead/ Developer/ Tester. This raises some questions.

Why is this happening?

I haven’t quite figured out [as yet] why if you are transitioning to Scrum, would you want this to happen – especially when Scrum Master is defined as a full time role in Scrum. The feedback I get is mostly around these lines:

  • There are not enough Scrum Masters available. We can’t just keep waiting for them to turn up. Hence, we identify people internally who can play this role. And, no one wants to do this role full time or take on this title officially. So, there we go. Do your 2 plus 2 is 4.
  • There does not seem to be any value in this role being a full-time – it is something you can do part-time. How much time can removing obstacles for the team actually take?
  • Serving the team, Protecting the team, Helping the team, Guiding the teams use of Scrum is something, which everyone should do and different people are already responsible for these things.

It is easy to dismiss or scoff at these [especially the latter], but these arguments actually seem to be true. I know for a fact that there are not enough Scrum Masters available [possible topic for another blog post]. I also know, that in an organization internally, not enough people are kicked enough to play this role. And, no matter what argument you give, the management is never convinced that this can be a full-time role especially when they see others doing this role.

Is this a good practice?

My views on “doing something just because ABC or some book or some user group discussion says so” are well known. Don’t do it. It is also said, that having no Scrum Master is better than having no Scrum Master. Before we address the question – Is it a good practice for Team Leads/ Project Managers/ Developers to be also Scrum Master, we must see what is it that a Scrum Master does. Like most things, lets start with Wikipedia, “Scrum is facilitated by a ScrumMaster, also written as Scrum Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverable. The Scrum Master is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the team and keep them focused on the tasks in hand.” Scrum Masters use soft power, servant leadership and trust to help the team become better. Scrum Masters also surrender complete control to Product Owner and the Team.   Some of the qualities we look for in a Scrum Master are humility, staying in the background, integrity and gain trust. We obviously see the clashing red flags here – the Scrum Master is not a leader. However, typically, the Leads/ Managers are that. The team is reporting to them. However, nothing that we talked about in Scrum Master’s role says that you can not have that with the team reporting to you or you working part-time as a developer/ tester. In fact, some people could argue otherwise. If you are a developer and you are convincing everyone to test, you can lead by example. So, let me stick my neck out and say – “I don’t think it is a bad idea.” It is always better to get the right person play a Scrum Master – like role half time than getting no Scrum Master or lousy full time Scrum Master. However, I won’t probably call them Scrum Master. I’ll call them Scrum Evangelist or Process Owner or Scrum Owner or something like that. Why a different name? Because, the team does not report to Scrum Master [yes, just because of that]. And, anyways, it wont be the name, but the intent and the action of the person that will play out louder in the transition scheme of things. Also, you should get these people [and the rest of the team and Product Owners] good coaching.

Some of these people [Process Owner or Scrum Owner] will make Scrum a bad word in the organization. But, so could many Scrum Masters and Product Owners [and even the teams for that matter]. The hope is that organization will pick the right people for this role. Like the rest of the organization, these people [whatever you have called them] will also transition.

Have you gone Beyond Agile Yet?

Posted in Agile with tags , , , , , , , on February 20, 2010 by vikramadhiman

Modern Agile. Post Modern Agile, Post Agile, Beyond Agile, Agile 2.0. Buzzwords 2.0 are flying right, left and center again. At conferences, at workshops and at twitterverse. This at a time, when people and companies, are still getting used to decentralizing and moving faster. But, do we need another movement, another thought process – at this time

Part of Agile’s [or agile’s] philosophy is “inspect and adapt”.  Agile is basically the agile manifesto and the values. I read the manifesto and the values many times over : whenever I am confused, whenever I have a question or whenever someone tells me that what I am doing or saying is not”agile”. From the clutter that surrounds discourse around Agile 2.0, the one clear voice seems to be that it depends : “You should be able to question the values too.” Being liberal at heart, I will concede that. Let us look at some values and see if you could do away with the values as such.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. There can be situations where “continuous” is not relevant and probably “early” in not relevant either.  Where exactly? For instance, in a financial application where tax laws are changing 3 months from now – you want to make sure you work towards that rather than focusing on early delivery [before the laws change in bits and pieces or focusing on usability releases while not having time for migration issues at the end].

Welcome changing requirements, even late in development Agile processes harness change for the customer’s competitive advantage. Ok! when you will word the last part of the sentence the way you have worded – pretty much no one will argue against it. However, the same phrase also means that you want to welcome changing requirements because it “can” lead to customer’s competitive advantage. What if it does not? What if its jut a whim of a product manager? What if it delays launch by a few weeks? What if the impact of change is not fully understood?

Just two examples and the generally dismissive note that people ascribe to post modern agile starts appearing like a judgment pronounced a bit too early. But 1+1 does not prove things sometimes. Hence, let us pick from the manifesto itself. The manifesto reads:

  • Indivuduals and Interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

As much as I think and re-think, I can not fault any of these above, in any context if I take out the mean and wicked sense that is. However, there maybe a need to be street smart in some situations. Hence, you want to make sure that your contracts are negotiated well even if your customer collaboration goals are high. Similarly, comprehensive documentation might be required in an outsourcing context. Responding to change vs. following a plan depends where you are. Too early in your product development, changing things frequently could result in chaos. And if your software team is fixing support bugs all the time, processes and tools might take precedence over interaction. The context varies and hence, your values would vary too. The keyword here is “context”. You might have to look beyond Agile Manifesto/ Values sometimes. Is that a radical thought?

I guess if we renamed everything to “contextual” software development or “contextual” management. Or, maybe this sounds creepy. Let’s just say Agile [consider it as an umbrella term] is one of the option available. The key is to realize that Agile [and not agile] is “one” of the option and “not” the option.

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.

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.