Posts about Agile

Learning to be Agile

Posted by Nilanjana on Feb 28, 2014 2:43:00 PM

For a team that has followed waterfall methodologies for years, moving to agile is not easy. We walk the agile path, and meander into our waterfall comfort zones. And when realize we are down the waterfall, we find our way back to the agile path.

It’s a continuous effort, because this is not only about a process to be followed. It’s about a philosophy to be imbibed, a way of living to be adopted. And so, that won’t come without an effort. We thought about some of the areas we tend to slip in. Here are some.

Going back to full feature than focus on stories

In the agile process, we work in sprints which ensure the chosen stories are completed. This includes the development, theming and testing. As a developer I need to focus on the story and then move it for theming or testing. But it’s very easy to lose focus and go back to the old way of development, which involves building a full feature or functionality.

In effect, a developer could end up coding out the entire feature taking up much of the sprint time. This leaves the themer and tester with little time to complete their work. Not only that, instead of them having to work on one story at a time, the developer ends up giving them a fat chunk of work to process further. This has huge impact on the sprint schedule.

Agile expects us to break the job into small tasks and focus on these tasks one by one. But it’s more fun to see the full picture, instead of a little part. That’s why we slip.

Going back into individual roles

Earlier, we thought of ourselves as developers and QA people. In the agile methodology, we get the work done, the sprint completed. And that means I could be a developer today and a QA guy tomorrow. But if I have been a developer for the best part of my career so far, I do find it hard to suddenly take on the role of a QA.But agile is not about who I am. It’s about what the team delivers. And if for some reason, any reason, the sprint is thrown out of gear, it’s my job to get in and do the best to bring it back on track. But many of us forget. We often go back to playing our individual roles, which could throw the sprint off track.

It’s a mindset challenge. It’s a shift from clinging on to descriptions we have given ourselves (or maybe others have given us).

Going back to hierarchy

In the waterfall methodology we would have team leads, project managers and other designated people to follow an hierarchical approach.  We knew who to go for problems, and who would drive the ideas and processes. It was easy to just be a follower, and do what was being told. Agile is a different ideology. You might not even have a role called Project Manager. It’s about focusing on the problem at hand and getting into discussions on how best to solve it and then go about doing it. And everyone adapts to the problem at hand. It’s being able to rise to the occasion, be what the situation demands you to be.

Each person probably could end up finding the leadership qualities in him. That’s probably a scary thought for those who have been mostly following. Some adapt easily, some keep slipping back to being followers. And when one person in the team slips, it’s likely to impact the rest as well.

Is your company on the agile path as well? Do you face these issues in your team? Or something else? Drop a note here.

Topics: Agile

How to find your Minimum viable product

Posted by Nilanjana on Apr 9, 2013 11:39:00 AM

So why do we then see so many failed attempts and burnouts in product development? Why do people end up burning money in creating something their users don't need? I will try and answer this question in the following post. But before that, let’s understand what an MVP is. Wikipedia says,"The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." This means a product that is built with maximum validation, but only has the minimum features that a customer requires.

Let’s understand how a Minimum Viable Product is shaped up at Srijan.


1. Structuring the thoughts

Let's take up a typical example of a product development exercise: A team of x and y get an amazing idea from which they can start a business. Usually such a team has had considerable work experience and they understand the business well. They understand its implications and are capable of creating and running the business. Excited with their idea, they are likely to jump right in and create an RFP with details of what they want. Usually, that RFP will have a plethora of features that cover almost every aspect of web development. Not enough thought goes into exploring why they are creating this. Even when brainstorming happens on the relevance of the features, they really don't know if their customers think the same way on the requirements. This is when they hire a development agency or a technical team to build their product. So the requirements are detailed out and each feature is built, without much thought on “Why are we building this feature?”

What's the solution then? Shouldn't it be easy for people to know what minimum features they want in their product? In reality, it's not that easy. Structuring the thoughts/features of a product into well-defined user stories/journeys requires the intervention of an experienced business analyst. Not many entrepreneurs or Product Owners (people from the product idea company who takes the lead in the product development management) have the knowledge of structuring and estimating the MVP.  


2. How Srijan helps in structuring the thoughts of the Product Owner

At Srijan we use Agile estimation and the backlog creation process to find the MVP for our prospects/customers. This is the most important exercise on the products we develop. After the initial engagement to create a backlog for the first 3-4 sprints (production cycle), we carry forward the project with a dedicated business analyst who helps in developing the architecture of your product.

When we start any engagement with a prospective customer team, we try to understand why we are building the product. We translate this into loose wireframes to capture the user workflow. During this process, there are several brainstorming sessions that take place with the customer team, documenting the thought process of a user and structuring it into a user stories backlog or wireframes. User stories capture the path of the user. See the example of a user story below:

How to find your Minimum viable product

If you look closely, it clearly defines a user workflow for a specific task. Now such a story allows a developer to understand how much time he/she requires to complete the task. This understanding is needed to craft the MVP.


3. Crafting MVP from structured user stories 

While creating the backlog, we try to capture all the stories that the product owner has thought through, and estimate the effort required to complete a story. The business analyst and the product owner start selecting the stories that require the minimum effort yet provide the basic functionalities to the user. This process of creating the backlog, estimating it under the Fibonacci series and then crafting the MVP out of this brings absolute clarity to the owner. He/she understands what he/she needs to create in the first phase with minimum effort. Also, note that this is a complete functional product with which he can go to market to test the waters and find out if the product makes sense to the users or not. The customer then comes back to Srijan with the market feedback, and the brainstorming on the required features starts all over again, leading to the new backlog of user stories. The cycle continues, till we have a product which is in sync with what the real users want.

Once we have identified the set of user stories which define our Minimum Viable Product, we staff a dedicated team to carry the development to completion. The team works on two-week sprints and runs a demo of the decided upon stories to the customer at the end of each sprint. The customer can review it, test it with prospective users and share the feedback.


4. Launching a Minimum Viable Product

Usually, in our first month of development, we are able to launch the minimum viable product for an initial set of users, who then give valuable feedback to help us develop the next version of the product. While launching, we also integrate a few valuable tools like VisualWebsiteOptimizer (for doing A/B testing), Crazyegg (for creating heatmaps, which allow admins/devs to understand user behavior with regard to design and functionality), and Google Analytics (for tracking and measuring traffic). We also use some more advanced tools like Clicktale for specific products. Tools integration can vary with the needs of each individual product.

After the launch, our primary goal is to understand user behavior and collect feedback to understand the next set of feature requirements. This iterative method is repeated again and again by creating the next set of Requirements → Wireframes → User stories → Development. Through this method, we remove a lot of development waste, and define our product features in a way that resonates with the needs of users.

We have successfully worked with many clients on building their MVPs, and as we grow, we are learning to make ourselves better. We at Srijan believe that being agile is just not about following a particular development process; the company needs to change its DNA to become agile in every respect. We have invested highly in training across offices to make our people better informed on agile processses, and are continuously refining our working styles to reflect the same.

We would love to hear from our readers on what they think of MVP, and their experiences of creating an MVP.

Topics: Agile, Enterprises

"My agile story: How we transformed our company"

Posted by Nilanjana on Feb 14, 2013 4:09:00 PM

On 01 Feb 2013, i presented at the the AgileNCR a talk titled "My Agile Story -- How We Transformed Our Company". It was great talking at an Agile conference - my second time (i'd earlier presented at the 2012 Agile Conference in Bangalore), but the first time i was speaking on a topic extremely relevant to Agile. My talk was around Agile Contracting, asanjaynd the change process that companies have to engage with and the stress leaders have to manage -- within themselves and amongst colleagues -- while moving from fixed-cost company to a long-term Agile contracts and Agile team-based company.

I was a tad unsure about the relevance of my talk and that too compared with a list of speakers covering heavy topics around SCRUM / XP / Kanban or Agile with remote teams or even Design Thinking.

But i realise that i am the top brand marketeer for Srijan, and such opportunities to showcase Srijan at such events, do not come by too often.

But this anxiety would not have held me back, as i realise that there is something valuable in what i have to share with the world in our journey at Srijan. We're a "good company" on our way to becoming "great". It is with such authentic sharing at forums such as this, is where Srijan's brand is going to be build, and the best people found. I realise that i am the chief story-teller for the values Srijan stands for at the moment. And it is thus my responsibility to present ourselves in spite of whatever excuses my mind may come up with. Also, the more i go out and talk and share what i have learnt, it brings me more clarity and creates a shared experience with the audience which is often "magical".

I guess the authenticity in my conversation worked. I've received rave reviews. Here's what the organizers had to say:

Please accept our heartfelt thanks and regards for your session at the AgileNCR-2013 conference held in New Delhi on 1st and 2nd February 2013. The session was really appreciated and we look forward to more such enlightening sessions at future Agile NCR conference.

We have collated the feedback from the participants and the details for your session are as below:

Rating ( on a scale of 1-5):  4.13

We are pleased to inform you that you have received  the highest rating among all the speakers. In fact one of the participants has given you 6 stars (given that there were only 5 stars).

Anurag Dutt, Xebia 

Awesome feeling!

My Agile Story - Presentation at AgileNCR 2013 from Srijan Technologies

Topics: Agile

Closing stories on time

Posted by Nilanjana on Feb 8, 2013 2:41:00 PM

At a recent internal demo of a project at Srijan, a conversation developed about stories being reopened in projects that followed the Agile methodology. The concern raised by the demo reviewers was that stories must not be reopened. Agile works on the mode of initiating and closing stories defined within defined sprints. So if the project sees a trend of reopening stories, it has serious implications on its schedule and budget.

Let’s look at the issues that lead to stories not being closed ‘fully’. This will help Srijan and other companies on the Agile adoption path to explore how they can ensure that stories get closed and velocity remains high.

For a story to be considered closed, our team needs to have its acceptance based on various criteria:

  • Srijan’s QA team lists the actions, functions and results related to a story to consider it completed.
  • The client could specify some criteria for the story to be considered completed.
  • Theming is a part which is done by Srijan based on designs provided by the client. If a feature is not presented in its right theme during a demo, the story cannot be considered complete. What happens in a demo given to the client at the end of a sprint?


If the client asks for a change that changes the underlying logic of development of the function, we create a new story, and call it a Change Request story. This is then addressed in a separate sprint later on depending on the demo schedule created.

If the client asks for a change that only impacts the display of a function and not the underlying logic, we handle it under a category like Bugs, or as a minor change request, but not necessarily as a new story. It is treated as a story that has to be addressed before the next demo involving that function. So when the next demo happens, the developer has to look at the change request addition/bug which is connected to an old story. So in effect, the story is ‘reopened’.

Theming has huge dependence on an external source in story closure. The theming team needs to have the designs with them well in time to enable a story to be made ready for a demo. If the designs don’t come, theming does not get done. So while a function or a feature is ready for demo, the lack of a theme renders it incomplete. So the story remains incomplete, or needs reopening, depending on how the Project Manager treats it.

So how to close stories on time?

  • Get a team and client consensus on how you will treat a change that only impacts the description of a story and not the logic used for its development. Should this be treated as a new story? Should we leave the story open till the change takes place? Should there be an added process/resource to close issues which do not require being part of a sprint?
  • Educate the client on the importance of delivering designs in time for theming to happen in parallel to the development. Often the client gets over involved in developing a perfect design and loses focus on when to make it stop, so the feature can get to A/B testing levels. The project manager needs to keep this key aspect in tight control to enable timely story closure. 

Have you faced any other instances that lead to stories being reopened? Are there some other ways in which we can better address these challenges. Would love to hear from you.

Topics: Agile

Falling into a Scrum-bug's trap!

Posted by Nilanjana on Sep 27, 2012 5:38:00 PM

Time for some more "Agile" Gyan!

Srijan as a company have now fully embraced Agile as THE methodology for development projects. Journey has not been smooth in any way! Spill-overs, bugs, managing sprints, bugs, story points breakdown, bugs, daily stand-ups, bugs.... you get the drift! Amidst all the mini failures and successes the most important piece that has been the biggest factor in our slow growth are the bugs that keep coming up in every sprint!

Why are bugs a nuisance!

We are having a hard time figuring what to do with them specially in an agile scenario where right after the demo we were to spend time in Sprint Retros and then the very next day prepare for the next sprint! UAT from client usually takes a couple of days. By that time developers are nose-deep into the next sprint tasks. How do we THEN handle the bugs that might be reported by the Product Owner/Stakeholders. Bringing in bugs in the new sprint could be suicidal. Developers might lose focus and worst lose velocity of development. Keeping bugs for the next sprint (Our sprints are two weeks long) could frustrate the stakeholders for lack of responsiveness!

What the community is saying

The Agile community is divided on whether the bugs should be part of the sprints or they should be handled entirely seprately.

While George Dinwiddie, Agile Coach suggested “I would start to ask the question why weren't they found and fixed within the sprint that they occurred? My focus is on reducing the time it takes to discover (and then fix) problems. After all, if we discover a bug in the story during the sprint it is written then the PO shouldn’t accept it as being done. In addition early discovery will make it much easier to fix as the code is still fresh in the mind of the development team.”

On the other hand, Mike Cohn from Mountain Goat Software suggested that the bugs be added to the product backlog and left to PO's discretion as to whether the bugs warrant immediate attention or can be tackled later.

Solution arrives

The churn has been so intense that we had to figure out a solution and that too real quick! We recenly came across a power-packed presentation by Matthew Saunders (Trellon LLC) titled "Agile Gymnastics and Timebox Tumbling" at the DrupalCon Munich. The idea there was to emphasize on how agile can be made effective by using timebox approach.

Picking on the idea we realized that making bugs part of the sprint where they have been found, is what stakeholders/PO can agree upon and developers love too! 

Here is a snapshot of somewhat similar (but tweaked for Srijan) approach 

Agile 2 weeks


The cycle is self-explanatory but the point of deflection is the time for the demo. A couple of days before we ACTUALLY used to do them.

What this approach does neatly is to allow the Product Owner and/or stake holders to do a good UAT and come back with loads of bugs. Developers on the other hand arent yet busy stressing about the next sprint and can certainly and very quickly put there heart, mind and souls towards fixing the bugs. Development team can also raise flags during the same time on any enhacements (scope changes) or bugs that might take too long to be fixed. Product Owner can be  informed about the need to push bigger bugs to be solved in the next sprint and yet all smaller, quick-to-resolve bugs can be put out of the way in the same sprint rendering the release more stable!

Out of the trap?

We had a client who very recently asked us if they have to pay for the bugs that come up during the sprints. The question being loaded and very subjective, we had to think through before answering.

Developers do believe that bugs only exist because usually the requirements may not be clear in the first place. Or they might be different in PO's head and translated differently to the development team. But they also agree that some times the code is the culprit and does not deliver what wa expected of it. Providing some time to the developers during the sprint to fix bugs means everyone in the team can concentrate on hard UAT (alongwith  the client) and hevay bug-fixing. This doesnt look out of place, being in the same sprint and it also fulfils the Agile idea of 'done' in terms of a sprint end.   

Curently the stake holders on various projects are sold on to this idea and developers seem happy too! The measure of success would be sturdier sprint releases and of course happier clients!

Topics: Project Management, Agile

How Agile is transforming our workplace!

Posted by Nilanjana on Sep 2, 2012 11:37:00 AM

Here is where we were at Srijan about a year ago:

  1. We wanted to break away from short-term one-off projects to long-term contracts
  2. We were struggling with our projects estimations leading to massive project over-runs most of which we had to absorb, hurting our financial health; in most cases it was the tail of the project dragged on endlessly messing up our finances
  3. Developers were often shuffling across multiple projects; they were often overworked; this was hurting their morale as well as the quality of code/work
  4. For years we have encouraged team behaviour and self-organising (non-heirarchical) teams that offer 360 degree feedback and thus learn collectively; reviews are central to such learning teams. We were struggling to setup "project review" processes
  5. To improve our financial health, as well as cover up for our increase in estimations, we increased our hourly rate by a huge percentage. This often made us non-competitive in projects bids.

All this put together was stunting our growth potential. We were struggling to earn decent amount of profits year on year - even after putting in so much hard work, showing tremendous commitment to our clients (and their projects), and having great set of core values.

This blog is *not* meant to detail how over one year we have come out of this, and marching strongly towards towards creating value for our customers, our employees and finally after all these years getting into financial health. But i do want to offer a peek into how Agile processes aligned with an organisation culture can bring about profound and rapid change.

Here is a workflow that defines how, almost each part of a company can be touched by Agile processes - project induction, project reviews, client engagement and satisfaction, employee engagement (leading to happier work environment), code and software quality, hiring (good, and often expensive, people), cash flow management, and even marketing.



We also shot a video recently which would offer insights how Agile is transforming us. Here it is (with my apologies for the rather poor quality of audition and lighting - apart from being nervous myself, this was our first experiment with shooting videos internally):

Topics: Agile

What Agile is! What Agile is not!

Posted by Nilanjana on Apr 26, 2012 1:56:00 PM

There are way too many notions going around about Agile, especially for companies in early stages of adoption, such as ours.

Developers and managers making the transition do not realise the intensity and deep responsibility Agile brings into day-to-day practice.

Here is an overview which may not be by-the-book, but common sense and learnings captured from my discussions and introspection


Topics: Project Management, Agile

Making the shift towards an agile development process

Posted by Nilanjana on Nov 9, 2011 2:12:00 PM

As a company Srijan is slowly, steadily making the move towards Agile development. The whole process of Agile is great, but it seems it is ideally suited for Time-and-Material kind of projects where the customer and the project team have a HUGE amount of faith in each other - the sponsor feels that the development team has adequate technical competencies and integrity to give their reasonable best effort. The development team must trust the sponsor to continue to sponsor the team with adequate funds during the various sprints, and evolution of the product.

However, we do not live in an ideal world. Most (if not all) projects have a "fixed deadline", and "fixed budgets". Given this, what is the best way to manage an Agile development process within a defined end-date. This is challenge we're grappling with internally at Srijan.

Here's the scenario:

  1. Sales sold a project with estimates done by an expert internally (not developers; but a CTO or a Tech Lead or both)
  2. During our estimation process, we break down the project to as much detail as possible (i must mention here that this does really drain our sales and tech resources, as not all project pitches we make convert - obviously)
  3. After much debate we agreed to ensure that we put the all tasks and key functionality - as has been estimated - into a macro-project-plan with the developers who are going to be working on the project; and share it with the client
  4. This would ensure that  we are sure that the deadline we have sold is still achievable with the current team taking account of holidays (company and developers)
  5. Ideally, at the project kick-off stage itself, a re-estimate of all tasks should be done
  6. The challenge that we are seeking answers for - is that if we do re-estimate the complete project at this stage which may require detailed planning - then the process does not really remain Agile; it becomes a Waterfall method of project development and planning
  7. The only Agile process then that remains, is within this larger/macro estimate where we can do detailed Sprint-planning
  8. In this process then, we have to ensure that the sprints plan sticks to the larger project schedule as communicated to the client in the first place; and if slippages in this schedule are expected, then they are absorbed by the development team by working extra hard

This is our challenge, and part of our process evolution at our company. What are you thoughts? How are you making the shift to being Agile from Waterfall development processes? We would love to learn from our readers.

Topics: Project Management, Agile

Case study: Agile development at Srijan

Posted by Nilanjana on Jan 20, 2008 4:01:00 PM

In my earlier post, I touched upon the processes we go through while designing and planning for a project. This entry is a more detailed look at the initial phases of such a project. The application under discussion is highly focused and yet multifaceted, therefore it would seem surprising that much of the concept was crystallized during the development process. Together, the client and the project team at Srijan cut and polished the initial rough concept into what it is today, a mobile based coupon delivery and redemption system which is supported and enhanced by methods both online (i.e. a web application) and offline (i.e. printed catalogs). We had spent months answering fundamental questions like what the application is supposed to do and who were our target audience. At the end of this process, we had a clear aesthetic and business vision. However, it was also understood that features had to be implemented for real to see how they work with the overall vision. Agile development was more of a necessity here than just one of the options we had.

Our version of agile development

Some of us were already practicing agile development for more than a year. Though these were home grown methods inspired by multiple sources, they seemed to work well for us. Rather than following established methodologies like Scrum or XP, we decided to formalize our own processes and adopt appropriate tools. Our method revolves around iterations. All iterations must yield tangible results. This way, the stakeholders can use the software and provide us with feedback which can take the form of change requests, bug reports and sometimes wholesale scrapping of features. It is not necessary to implement change requests and new features in the next iteration, but bug fixes should be immediately scheduled. The focus of the iteration is on completing allied features; however we aim for 1 or 2 week durations. Once work on the iteration has been started, any change in plan has to be deferred until the next iteration. One or more iterations can lead up to a release, which is more public in nature and expected to be used by a larger group. To ground these practices and allow easier collaboration, we decided to use Mingle for transforming the requirements into user stories. In addition to the user stories, we create an iteration plan document which tells the reader exactly what the iteration is supposed to achieve and each participant’s part in it. We prefer Dokuwiki, a free wiki which is simple to use, yet offer adequate access control mechanisms. We have created a PDF generator plug-in for Dokuwiki, which allows us to generate printer friendly documents for distribution. The client had some deadlines by when they would like to see certain features. The stories were accordingly separated into iterations so that features were grouped by dependency and priority. We collected iterations into releases and then started on the iteration plan.

Design decisions and platform choice

Since we knew we would have to plug in and rip out components often, the primary design goal was to keep functionally distinct components loosely coupled. The database would be used to connect components and preserve state as much as possible. The following things were in our mind when we decided on the platform:

  1. Features could be implemented with minimal code so turnaround time is low. However, flexibility is equally important and granular customizations should be possible as well.
  2. Practical considerations like availability of developers, our efficiency with the chosen platform, etc.
  3. Modular architecture, so that developers can be responsible for a functional area and modules can be replaced with minimal fuss.
  4. Enough built-in tools and components to get us up and running fast. An example would be some out-of-the-box admin interface which would suffice until we decide to build a custom one.

Despite a plethora of choices, only Symfony and Django web frameworks seemed to satisfy all criteria. We had worked with both and preferred Django. But we chose Symfony since it was built on PHP and we had immediate access to a larger pool of PHP developers in our organization. It was decided that we would continue to use Python for components not connected with the web application such as sending and receiving of SMS, etc. The rest of the platform more or less fell into place; PostgreSQL as the database since we envisaged using stored procedures and other similar features, Apache 2 as the web server and so on. We decided to use Sphinx as an indexing engine to reduce load on database for search and also to improve response times in general. Sphinx was chosen over other alternatives since it was fast and had good bindings available for both PHP and Python, which would turn out to be very important later.

Initial hiccups

The first iteration was primarily about getting a structure up and running which would tie the different components together. Though this was accomplished without difficulty, we foresaw problems if we continued with Symfony. Apart from minor irritants like configuration duplicated in multiple places, there were major issues as well. Propel, the default ORM would not reliably generate foreign key relationships. Since good parts of our application were linked through the database and it would be responsible for data integrity, this flaw was unacceptable. We knew that there was an alternative ORM called Doctrine, but we were not willing to spend significant development time to learn its quirks. We could have written custom SQL every time we changed something in database, but that would slow us down. After much deliberation, we decided to switch to Django since it was free from these issues and had all the advantages of Symfony. Most of our aforementioned PHP developers were occupied at that point and thus the sole advantage of Symfony was nullified. Since the application was loosely joined, it did not take more than a couple of days for the switch and large portions of our work could be reused.

Current status and future outlook

After many iterations and a couple of releases, the application is now almost ready to be rolled out. Of course, there were slips during development. At certain points, we had to change plans in the middle of iterations. The later iterations were not as brief or clear as we would have liked. In some cases, tests were written after major work was done. However, in the end this was one of the smoother projects we have done thanks to agile methods and our initial design decisions. We are confident that it is a good platform for future improvements and additions as well.

Topics: Project Management, Life at Srijan, Agile


Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us