Archive for SCRUM

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.

Beginners:

  • 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?

Intermediate:

  • 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?

Advanced:

  • 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 :-)

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.

When Should You Implement Scrum or Agile?

Posted in Agile, Change with tags , , , , , on August 19, 2009 by vikramadhiman

Are there circumstances that are more favorable for implementation of Agile and Scrum and ones that are not very favorable for its implementation. Generally, the ideal conditions for implementation and spread of Agile/ Scrum in an organization depend on the market and customer scenario, rather than the development team scenario. Some such factors or conditions include:

  1. Unclear product direction or a research oriented product – the fact that the direction is unclear, makes you plan only for a small time in the future, when you reassess and reorient
  2. Too many changes/ feedback too often in the product – again this means that you take the minimum [agreed, clear or consensus] work – complete it – get feedback and move from there
  3. Competitive industry/ market scenario – this generally would mean you have to get the features out to the market sooner rather than later as well as have more customer connect in the product [some will argue this should be the case anyways]

There are some factors at organizational end as well, which can impede/ aid the Agile Implementation. For instance, if there is no management buy in, or team buy in or worse if there is no customer buy in [in service industry scenarios]- it will be hard if not downright impossible to implement Scrum, Agile or any other framework. In addition, where a deliberate slow and assured pace is mandatory [think software for nuclear reactors or space ships] – there might be significant overhead. Hence, small increments or sprints might not be possible in such a scenario. Turning, this around, you should go all out to implement Scrum or Agile, if:

  1. There is a relative buy in at all ends – customer>>management>>team [not necessarily in this order in all organizations].
  2. The cost of a single bug is very high.
  3. Everyone understands or make attempts to understand what is Scrum or what is Agile.

When you combine the outside [market/ customer] conditions with inside [organization] factors – you get a ripe condition for implementation of Scrum or Agile.

Agile and Scrum Jobs in India : Beginning to Appear?

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

It seems after about 03 years of activity on the Agile and Scrum jobs are beginning to appear in Indian job portals. Naukri displays 109 jobs for Scrum and 296 for Agile as of today – 5th August.

About a year back some of the developer jobs started adding a line “Experience with Scrum/ XP/ TDD is an advantage”. This continues to date. Here are a few such jobs:

  • An opening with http://www.truglobal.com/ for Senior .Net Developers :  The desired profile is “.Net 2.0/3.0/3.5 (WCF, REST, CLR). Strong database skills. Exposure to Agile / Scrum methodology is mandatory. Linq, ASP, VB, OOPS, XML and JQuery” Contact recruiter@truglobal.com
  • Another job is from Parexel International at Hyderabad. The requirements are “4+ years of commercial development experience Educated to minimum of degree level in a science related discipline Highly proficient in English (written, verbal and comprehension) Following Must Have technical prequisties: Java 1.5 —- J2EE —- Struts 1.1+, JSTL —- XML —- XSLT HTML/XHTML —- Servlets/JSP —- JavaScript CSS —- JDBC —- SVN/CVS PL\SQL —- Oracle 10g+, —- Tomcat 5.5+, OOAD —- Formal SDLC-Waterfall/Agile —- JUnit Desirable prerequisites: Sun certification ‘ SCJP/SCJD Knowledge of Integration middleware platforms, or SOA Pharamceutial/Clinical Trials industry/domain knowledge Following technical prequisties: IntelliJ –UML –Apache Derby ANT –SQL-SQL92/ANSI –VB6 Linux –JBoss –Glassfish WebLogic –OC4J –Websphere AJAX –Web Services –Scrum Report Development –Portal Development-JSR168/286 –Workflow JIRA Development –CheckStyle/PMD/Findbugs” You can submit your resume at
  • Symbian Developers in Bengaluru can apply at Tata Elxsi Ltd. The exact skills required are “Debugging Tools in Symbian platform – Emulator, TRK , ODD using Carbide and Lauterbach etc,  Tracing and Profiling Tools – TRACE32 ,Profiler and analysis of profiler data, Emulator – In depth knowledge of Emulator provided by Symbian / S60 SDKs, Compiler – Various compilers supported in Symbian platform, Memory and Code dump Tools – Hook Logger and other Tools available in Symbian / S60, Core dump and crash log tools – Crash Log analysis and associated tools, Awareness of Symbian foundation tools, Static code analysis tool – Coverity Prevent Tool, Experience in Agile development – SCRUM and Knowledge on PERL.
  • There are jobs in North India too. There is one available through Vanguard HR Consultancy. The job is of a Senior Software Engineer – Java. Contact Mayank@vanguardhrconsulting.com and you need to have about 06 years of Java Experience with Agile/ Scrum methodology. Specific skills required are “Extensive experience of J2EE application servers and Java web applications, Should have worked in at least 2 previous large database backed Java applications, Should have good understanding of robust database schemas and database tuning,
    Should have worked on large scale databases, Experience with JSF (Java Server Faces), Spring and Hibernate and Should have a thorough understanding of email and SMS, technology, protocols, etc.”

There are other jobs available as well. Here is one for a Senior Technical Writer from Consona. “Experience working in an agile/scrum development environment” is one of the requirements along with standard technical writer jobs.

The big guns are hiring for dedicated Scrum Coaches. As of now, Dell wants a Scrum Master for its R&D Division in Bengaluru, there are at least two product companies looking for Scrum Coaches in Pune and there is one requried at Nokia as well.

There would be others which never get listed and are filled through reference or community events as well.

However, despite these jobs being listed, I think we are still some distance away from getting more jobs in Agile and Scrum space in India – especially Scrum Masters/ Agile Coaches/ Product Owners. But the things are better and over the next one year, it should be even better.

A Successful Retrospective

Posted in Retrospectives, SCRUM with tags , , , , , on July 31, 2009 by vikramadhiman

Someone asked me when do you know if you just led a successful retrospective.

My first reaction was that I will have to think and come up with some metrics which optimize the complete value chain. However, I started answering sooner than later. I stopped in between, reflected and continued. On the flight back, I reflected again on what I said. I thought it made sense. Let me know what do you think?

An effective or successful retrospective should have the following characteristics “come out”:

  • No one should come out of the retrospective with ill feeling or negative thoughts towards anyone.
  • No one should come out of the retrospective thinking they have not been heard properly.
  • No one should come out of the retrospective saying they are not a party to this decision.
  • No one should feel that the real reasons or suggestions did not come out.
  • The team (and PO – if he/ she was present in the meeting) should be buzzing with enthusiasm in being part of something unique.
  • The team (and PO – if he/ she was present in the meeting) should come out of the retrospective with more understanding about each others roles, expectations and requirements.

I think this made a good checklist – mentally, for a Scrum Coach.

What is a Sprint Review Meeting | Iteration End Review Meeting

Posted in Agile, SCRUM with tags , , , on April 9, 2009 by vikramadhiman

When a sprint or an iteration ends, the time comes to demonstrate the working software as per the stories and requirements committed originally. This is usually done in what is called a Sprint Review Meeting. During the Sprint Review Meeting,  the team demonstrates working software corresponding to project backlog items they have completed in a given sprint.

The focus of sprint review is on working software. Powerpoints, speeches, lectures and other diagrams/ presentations are not allowed. In fact overall, the meeting is kept very informal. and typically, like the Sprint Planning Meeting, last only about 01 hour per week of sprint work planned. The teams attention, selection of practices and processes is all done with regards to faster delivery of working software. For instance, since the teams focus is on delivering working software, all the arrangements [arranging room, projector, getting the environment ready etc.] are done by the Scrum Master.

Product owner, The Whole Team and Scrum Master, all attend the Sprint Review Meeting. This is done to ensure that people who have developed the software are there to answer any questions the product owner has and for product owner team [customers, stakeholders, product owners] to see what is coming up from development team. This also improves the communication in the team, with each team member further strengthening the teams understanding of the product and product owner expectations. The team would typically demonstrate each code it has written either through GUI, mock objects or through API calls. The product owner team can give better feedback after seeing something working rather than on abstract IT diagrams. The teams are looking forward for the following feedback in the sprint review meeting:

  • Whether they completed enough requirements
  • Whether they completed requirements quite early
  • Whether they understood the requirements and translated them to working features well enough

This feedback helps the team and product owner to plan better for the next sprint. The team [together] and product owner both take back points for themselves too. For instance, product owner sees if some more requirements need to be added/ edited/ deleted for next sprints and also for the team to see if they need to do better to understand or compelete more requirements.

After the sprint review is over, the date for next sprint review is announced and the team moves to Sprint Retrospective.

A Sprint is different from an Iteration

Posted in Agile, SCRUM with tags , , on March 8, 2009 by vikramadhiman

In other frameworks under Agile, the term iteration is used to define the time period in which plan and develops an increment of functionality. So, why introduce a new term – sprint in Scrum.

The obvious answer [and correct one too] is that Scrum borrows a lot of terminology from Rugby [including the word Scrum]. A sprint in Rugby is a distance an athlete would travel from one end to another. Before an athelete or team would sprint, the team would quickly get together and plan how to go about it. During the sprint, an athlete would encounter opposition from the other team and might go ahead with the plan [if the plan still is good] or more likely alter the plan. You can anticipate but not predict the opposition. A sprint tests whether the team is a team, whether they are good or not and their ability to respond to change. It is clear to see why sprint is an appropriate terminology for Scrum. A sprint in Scrum is a time period (can be anything from 2 to 8 weeks) in which the team does whatever it can to develop software as per the features/ requirements that the Team has committed to. It is important to note that during a Sprint, the team not only iterates towards a final product solution, always improving on what they already have, but also take on some additional increments. Hence, product is developed iteratively and incrementally during a sprint. The term iteration can sometimes fail to capture the incremental part of product development during a sprint.

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.
Follow

Get every new post delivered to your Inbox.