The realities of trying to do Agile in a CMMI environment

Outsourcing is hard. Trying to do agile in a Capability Maturity Model Integration (CMMI) level 5 environment is damn near impossible. Without even discussing lean, let’s start by getting the basics down and first examine how one can start thinking about doing Agile with SCRUM in an enterprise development before tackling outsourcing. CMMI defines the what, whereas Agile lets you in on the how. This blog post aim to highlight some of the challenges you will face when bundling Agile with CMMI. To help stay the course and hit the ground running, a simple summary of my key takeaways based on previous experiences are provided. Most importantly, go sit the Scrum Master/Product Owner training. It is worth the 2 days.


The assumption here is most people get CMMI wrong. A quote from the father of CMM, Watts Humphrey, “Work on you quality and processes first, the levels will come by themselves.” This by nature is agile, an implicit continuous improvement if you will. Unfortunately, the pursuit of certification has landed most adopters and practitioners of CMMI into the Waterfall model as we understand it today. As an interesting side note, the Waterfall model since its conception is not, nor has it ever been a single rigid software development life cycle. Most people misunderstand it and simply ignored the rest of the paper after the abstract, see “The art of destroying software.”

For me, CMMI level 5 conjures up an image of Jedi masters/ninja coders, industry thought leaders that are constantly optimising, learning, sharing, and challenging the status quo. My experience thus far is the exact opposite. Unfortunately for me, CMMI level 5 has been an environment with large amount of unnecessary restrictions, heavyweight processes, meetings, coupled with documentations that nobody reads or maintains. Worst case scenario is that useless documentation exists where nobody understands the content. Let’s not even begin to explore the notion of devops or fullstack as CMMI is a siloed model that ties everything together through processes, and you guessed it, meetings. A quote from a man I respect very much once said, “Meetings keep you busy, and not spending money.” The reality is that CMMI is typically completely wrongly applied, but complacency or fear of change makes CMMI the prime roadblock for doing anything Agile. In a devops world where Agile is considered way too heavy, CMMI appears to be out of the stoneage.

An interesting fusion of both CMMI and Agile started to surface nearly half a decade a go. Supported by some academics, CMMI is slowly incorporating and adapting to Agile. However, the practical aspect of transforming a rigid siloed team into a some what agile setup is a monumental shift in paradigm, all too often hampered by organisational pushback. CMMI is not going to catch up anytime soon as it continues to waddle in the back of the bus with its late adoption of Agile. Currently CMMI 1.3 for development has incorporated Agile into the processes. Services and acquisition has been left outside alone (it’s cold out here). Overall, one does not have to look very far to get a sense of the magnitude and complexity of CMMI 1.3.

The Agile Manifesto: the values

Let’s take a breather from CMMI and rehash the Agile Manifesto. Hark! Let us ask in their wisdom.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto: the principles

The following are the principles of Agile. Truth to be told that it is arguably easier for startups or development houses to be Agile than enterprises. Limited budget and human resources usually breed clever ways to address ever changing requirements. Light organisational structure also helps. However, the bottom line is that Agile principles are the same regardless of budget and team size. These principles are proven and battle hardened and are well suited for both large or small organisations.

  1. Satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  2. Business people and developers must work together daily throughout the project.
  3. Build projects around motivated individuals.
  4. Give them the environment and support they need, and trust them to get the job done.
  5. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  6. Working software is the primary measure of progress.
  7. Agile processes promote sustainable development.
  8. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What the Agile doesn’t tell you – key takeaways

All agile methodologies will help highlight the pain points quick and early. However Agile is not the silver bullet for solving these pain points, it is up to you to address them still. The real difficult barriers are usually organic, organisational, and cross-functional.

Expect change. A lot of changes. This is the essential first step towards lean, and it is going to be a painful one for some. On a positive note, being fluid and adopt to change is all part of being Agile.

Juggling SCRUM with regular traditional project management status updates will be tricky. Try Commitment-Driven SCRUM. See Commitment-Driven SCRUM.

CMMI usually requires a fixed price contract based on some fixed estimation. In order to correctly estimate the work involved, the type of tools, platforms will be rather monolithic and probably inflexible. New technologies are not part of the CMMI game. This is the exact opposite of Agile. Though CMMI is suitable for certain application domain, it is important to find the balance and not let CMMI swallow up every facet of I.T. Marketing and sales would rather have new prototypes instead of a mini ERP.

Lastly, Agile does not dictate what methodology best fit your organisation or team. Remember, the team should pick their own methodology appropriate for how they wish to work and interact.


If outsourcing is part of the gig, have a read the following 3 part blog series on outsourcing and SCRUM I wrote nearly two year ago. It is still applicable today.


Commitment-driven SCRUM

“They always say time changes things, but you actually have to change them yourself.”
― Andy Warhol, The Philosophy of Andy Warhol

Burndown at the end of a sprint is indicative to a team’s velocity. This equates to the amount of work a team can squeeze out of a single sprint. After a couple of sprints, as a team gains domain experience and knowledge, velocity is expected to improve. With this in mind, how does one go about answering these quinella?

  • When is the release date?
  • How much is this costing us?

This blog post aims to answer the above questions, and provide a SCRUM spreadsheet as a tool we use for commitment-drive SCRUM.

The real-world lo-down

Let’s take a step back. If you do SCRUM properly, the question of release dates is moot. That is having a potentially releasable product, which can be pushed out to the world at moments notice, is a utopian scenario for any product managers. This is achievable only through hard yakka and paying down the technical debt, one -ilities at a time.

Externals in the SCRUM team? By adding billable consultants to the team one may start to wonder how much is any of this costing us and is this going to eat into our slush fund?!

Further complicating the overall picture, in the real world, engineers are usually not confined to a single role, task, or team. Some of us do presales, training, support, consulting and generally split our working efforts in various activities (even blogging!). The annoying thing with velocity is that, these “other” activities that are not part of the sprint backlog are categorised as interruptions and/or blockers. These interruptions ultimately impact the team’s velocity. Traditionally if you are a product development team, your central role is to build features, fix reported bugs, and push out releases. Not presale, not training, not support and not consulting.

Support is indeed tricky. Typically one is unable to estimate how much support may flood in. This is at loggerheads with the notation of an agreed sprint backlog. Though this can be mitigated with lean principles, WIP and cumulative burndown, but that is not SCRUM and the discussion is for another blog post, another time.

User story points vs man hours

If you come from the SCRUM school of Mike Cohn, like me, you should already be tut-tutting, arms crossed and ranting, “one should not measure velocity in man hours but in user story points!” However if you have a steering group asking for the release dates and cost of development, or you have external consultants billing hours on the project, you know the only measurement that really matters is man hours, which can be directly translated into a monetary cost.

Using man hours is a double edged sword. The clear benefit is that you are immediately given a sense of expected delivery. This contradicts the central premise of user story points, that a task should be measured on its complexity and size based on a common understanding and analysis. At this point we are unsure if time-based estimates are better suited for us than user story points.

The other issue with time-based estimation is that team members may find themselves giving dishonest estimates, be it too optimistic or pessimistic. Be weary of people touting “oh they build xyz in just one day.” Or, “it’ll take me 10 years to do xyz”. Both quotes should trigger alarm bells.


Most engineers are used to percentages as an indicator of commitment. For example, “I’d spend 50% on project A, 20% on project B, 10% on meetings and doing expense reports, and 20% on water cooler conversations this week.” is not unheard of. This simple model fits our sprint schedule, where one could identify their non-working days ahead of time, percentage of working hours for each projects and tasks, and a preliminary prediction on admin and meeting hours.

Naturally none of the existing SCRUM tools of the world currently support the notion of commitment. Therefore as part of evaluating our tools and processes, old school spreadsheet was deemed worthy of a revisit. I have come across some of the most comprehensive SCRUM support and prediction models that was entirely written in Excel. So I was not too surprised that we stumbled on this stirling little pearler of a SCRUM spreadsheet, by Xavie Esteve. The spreadsheet has a great burndown chart and uses estimation in hours. It is simple to get started and we loved it. I extended it with calculations based on commitment, helping to determine if we have fit the right amount of tasks based on the predicted maximum velocity. The end result is here and the following were added.

  • Theoretical maximum team velocity
  • Reduced max team velocity based on planned engagements
  • Adjusted max team velocity based on adjusted capacity based on unplanned engagements
  • Recommended daily burndown per person

All calculations above take into account vacation days, public holidays or any other planned non-working days.

The biggest benefit is that we used commitment to incorporate other tasks in our estimation and sprint planning. For example, individuals on weekly support are capped at max 50% commitment to the team.


The spreadsheet is an excellent starting point. But it really lacks the overall picture. The following would be fantastic to have.

  • Task assignment and notification
  • A sprint board
  • Re-adjusted daily burndown prediction based on unplanned non-working days or engagements
  • Calculating expected velocity based on previous sprints, perhaps based on an average or median

As a side note, we are still evaluating other options and tools. Stay tuned.

I’m calling it! Is design synthesis or requirement automation a reality today?

After devoting my post graduate years in automated design synthesis, at times I feel the need to evaluate the relevance of my work against modern tool chains and trends. Automated design synthesis aligns with *DD frameworks and I feel, with tool chains supporting continuous integration, that automated design synthesis may now actually be a reality. A form of requirement automation if you will.

The core principle behind DDD, TDD, BDD and ATDD is about writing code that aims to deliver implementation for requirements. The mapping is 1 to 1 and it is often an iterative process. In order to illustrate that the code correctly behaves as designed, artifacts are produced to directly support testability and serves to illustrate conditions of satisfaction.

Peeling off yet another layer, all *DD principles focus on encapsulating requirements using regular language, then forming individual requirement pieces into regular expressions. Regular expressions are equivalent to deterministic finite automata (DFA) and therefore can be combined with other DFA via Kleene’s theorem. This is the crux of design synthesis and code generation.

I surmise that it is now possible to perform requirement automation iteratively, from synthesising verifiable design artifacts, to executable test cases, to rapidly deploying these new implementation into production environment that are ready to be acceptance tested and released with moments noticed.

I hope to further examine this notion in the coming blog posts in order to fully explore the possibility of delivering requirement automation.


Taxonomy of DevOps in startups

Software engineering is changing and DevOps is at the heart of it. There are myriad of DevOps blogs and conference talks on transforming enterprises to more DevOps, usually centered around incorporating operational concerns early on software development lifecycle (SDLC).

An Enterprise Transformation

On a larger scale, Mike Kavis, VP/Principal Architect for Cloud Technology Partners, puts it quite bluntly on a post titled No, You Are Not a DevOps Engineer.

“Enterprises are struggling with DevOps. They all want DevOps even though many do not know what it is. In many cases, I see infrastructure teams who are calling themselves DevOps leading a grassroots initiative. When I ask them where the development team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.””

Kavis goes on saying:

“Another reoccurring pattern I see is that a “DevOps” team’s first step is often to figure out if they are going to use Chef or Puppet (or Salt or Ansible or whatever else is hot). They have not even defined the problems that they are setting out to solve, but they have the tools in hand to solve them. Often these teams wind up building thousands of lines of the scripts, which raises the question, “are we in the business of writing Chef scripts or in the business of getting to market faster with better quality and more reliability?” Too often, these teams code themselves into a corner with mountains of proprietary scripts that actually add more waste to the system, instead of removing waste from the system, which is what the driving forces behind the DevOps movement are all about.”

Arguably these are symptoms specific to big enterprises, where traditionally massive engineering silos exists with minimal communication coupled with ticketing/queuing systems in between departments. But are startup basically immune to these symptoms?

Definition of DevOps

I agree with Kavis that DevOps is not a role or job title, it is not an engineering discipline nor a methodology or process framework. I also agree with this post, titled What Is (Not) DevOps, and How do We Get There, that DevOps is a culture shift. It is a movement that encourages and improves communication, collaboration, and fosters quality software product delivery through tight knit teamwork.

Daemon Edward, Co-Founder of DTO Solutions stated in QCon London 2014, titled Dev “Programming” Ops for DevOps Success, that the definition of DevOps to him is

  • a way of seeing your problems
  • a way of evaluation solutions
  • a way of communicating these things
  • always evolving

I wholeheartedly agree.

DevOps taxonomy in startups

Arguably the size of startups and the limited resources requires every technical members to be all-hands-on-deck, participating in all aspects of SDLC. Often those that are slightly more interested in Ops would take the lead in addressing the many -ilities in requirements and release management. Those more interested in Devs would take the lead on churning out code and test automation. Based on the lack of resource and the inherent drive and focus of a startup, the taxonomy of DevOps in startups would be the following:

  • -ilities are addressed as backlog items during development
  • Release/production concerns are on the table from day one
  • Teams have a tighter bond, communication channel transparent
  • All efforts are tightly mapped with tangible values (be it business or customer)

The DevOps sweet spot

It would appear that startups are DevOps havens. This would not be the case. Startups are not immune to the aforementioned problems in larger enterprises. Silos do exist in startups, be it a single man team or hundreds. There are plenty of pitfalls along the way. In my experience, I believe in the existence of a DevOps sweet spot. The points below are my own guidelines for chasing that utopian DevOps shangri la.

  • Non-functional requirements, -ilities as features residing in backlogs
  • Build systems that makes managing easy for Ops
  • Foster a nurturing company environment for thriving Devs
  • Treat Ops as customer facing, sales/consultancy alignment
  • Treat Devs as business value delivery, marketing/R&D alignment
  • Adopt lean/agile principles
  • Last but not least, Stop, collaborate, and listen! (no wiser words have come out of the 90s)

Agile tools comparison: Greenhopper, Trello, Asana

Running an agile team requires hands-on tools that follows a particular agile approach, that aims to improve overall communication without burdening the team, all the while injecting a touch of urgency and accomplishment to keep everybody motivated and on track. Perhaps the least favourite of all for the team is being able to obtain performance metrics and observing the team’s overall progress. This is most certainly no easy feat and though there are plenty of tools out there, exposing the traditional MS Project or Omniplan to team members will neither motivate them nor encourage them to put in the hours that they have worked.

Few tools, such as Greenhopper, Trello and Asana are built with agile processes in mind. These are arguably the most elegant and useful agile tools I have ever had the pleasure of using. Though all three will provide the basic mechanism to run Kanban or Scrum, they are startling different.

To get started, I have used Greenhopper/Jira/Confluence to manage an offshore team with great results. I am using Trello to manage a smaller sized team in my current employment. Lastly, I use Asana at home with other members of the family to for carry out “tasks” such as holiday plans, events and so on. I know… its quite shocking, but it works really well! Before I start, I must express my great fondness to all three tools. There’s a place in my heart reserved for each of them.


This is by far the most flexible, most comprehensive, well integrated tool available. Greenhopper is a add-on for Jira, which is a bug tracking system from Atlassian. This tool basically has it all. A sprint / Kanban board of your liking, configurable fields, configurable performance metrics, and graphs that will make your manager weep tears of joy,

The flexibility allows you to formulate the Agile process custom to your needs. Adding a new field for business values, story points, and hourly estimation will easily yield you a burndown for each of the these respective custom fields. Figuring out how “real” or “accurate” the estimates are based on past performance is also something I stumbled upon with Greenhopper The built in cumulative flow diagram is also great for Kanban.

Users can like, upvote, or follow any of the tasks. Integration with Confluence implies that you can attach Balsamiq sketches, UML diagrams or any specifications to the tasks and still be able to keep these information all in one place, with history tracking.

With great power, comes great responsibility. In the case of Greenhopper, you will need to be able to model your Agile process directly into Jira. You will also need to be know well in advance how you are going to breakdown user stories to technical tasks, differentiate bugs from improvements, release versions, release candidates, epic stories etc. All of the aforementioned items are modelled in Jira and in order to best use Greenhopper, you will need to have ironed out majority of your own models and processes.

The entry level for Greenhopper is deceptive. As an Agile tool, its easy just like the rest. But one is required to be well versed both in Jira and Confluence, and perhaps with an admin account on Atlassian OnDemand to tame the Greenhopper beast.

The time vested in Jira / Confluence aside, this tool excels when the entire team embraces the tool and use Confluence and Jira for wiki and bugs respectively. When it is shunned and left to its own demise, it quickly becomes the big elephant in the room, bloated, heavy and a massive burden to the team members. Shame really.

I give this tool top marks for its enterprise approach, responsive and fast support from Atlassian (if you ever go the hosted or ondemand route), and most importantly, integration with the rest of Altassian ecosystem,


The free, easy-to-get-going virtual board for the masses. Trello keeps it simple, it most certainly keeps it real. It does not pretend to be anything else other than a virtual board. You put cards on it, you define the columns, users can follow and move the cards about.

It is simplicity at its best and it is fantastic for small teams, or with team members that are adamant about specific tools that they must use. This is a sure winner for smaller projects, small team size and comes at 0 costs.

Trello implicitly lets you define your process by the titles you put on your board and the columns that exists on each board. For example, a typical Scrum board in Trello can be defined as Todo -> Doing –> Ready for QA –> Done.

You can easily model your product backlog board as Ideas –> Business requirements –> Sprint backlog. In addition, we use it for retrospective and various other activities is not part of development, such as support or various other marketing activities.

The down side is that Trello does not support estimation of any kind, at least not out of the box. There are Chrome plugins and various other paid apps that will help plot and extract the burn down based on time or estimates. Unfortunately, these are still quite basic. You get an input box next to a task, place a number in there, then wait a few days, out comes a burndown.

There are currently no way to pick which field to use as performance metrics.

How does Trello inject a sense of achievement and urgency? It does not by default. However I can highly recommend that keeping your board tidy and fitted to each sprint or timeframe will most certainly address that. Nothing worse than having a bloated board, where all the team members have basically stopped caring about it and use it as a dumping ground for tasks they will never get to.

One nagging bit about Trello is the lack of search. Once a task is archived, it kind of disappears into the Trello void. If you do not archive them, it will very quickly make the “Done” bloated and basically unusable.

Trello gets top marks for its flexibility, the awesomeness of the sprint board. Simplicity at its best.


Asana is a bit of a mix bag. It smells like Greenhopper/Jira but without the heavy weight model. It smells a little like Trello for its beauty in simplicity, but manages to avoid the Trello void. Asana has ability to place items in a task list and prioritise them very quickly, while maintaining integration with say Dropbox. This is an interesting choice as Dropbox is fairly adopted as the go-to tool for sharing business documents.

Asana supports custom tagging of any tasks. By intelligently naming the headers, you can easy break down and categorise your product backlog, sprint backlog, and technical tasks. You can also very quickly differentiate epics user stories, make it into a priority heading, then flesh out the technical details.

Being able to hashtag any tasks in Asana is fantastic. It is made brilliant when Asana provides a great search function. Nothing is lost. Through using these hashtags, you can extract performance metrics based on the search results.

The downside to Asana is the task itself is not customisable. No burndowns or charts available either. Estimation comes in the form of “deadline”, which I guess is the traditional way of going through a task list. No Scrum or Kanban board here.


All three aforementioned tools are fantastic in their own right. There is no perfect answer or a perfect fit for your institution. I would suggest trying them out in a few projects, really commit to them and evaluate the results. The only common pitfall is that when members of your team stop using them, all the tools will very quickly become a burden and thus useless.

Lastly, if you are using agile project management tools at home, here is a cautionary tale – my partner hates it when I assign tasks. So like a good Scrum Master that you are, avoid assigning tasks even at home. Motivate and subtly inject urgency, let the team members pick tasks. Having said that, I am sure to be shunned at home for this blog now.

Outsoucing and Scrum: Retrospective

Retrospectives are fantastic opportunities where the team can discuss any issues regarding the project at the end of a sprint. I aim to share some of the experiences and findings written from the viewpoint of different roles in a software project. Together, it highlights the difficulties of outsourcing.

The Architect

Open source tools and API used in the project should be well documented and maintained.
This point is often neglected as architects pick high performance API, with little or no documentation. Remember that it is the team that has to live with the daily struggle of using the API. With poor documentation, the team loses focus on coding instead of squandering about on Stackoverflow, looking for a possible solution to their problems. The team needs to be comfortable with the packages, and poor documentation will always negatively impact the velocity.

Examples and clear documentation of a vertical slice of the system, a prototype, will help the team scale out horizontally. Having a clear structure and well defined interactions between components will help the team burn down faster.

Quality of code should be constantly scrutinised. Static code analysis tools will help.

Knowledge sharing and training is encouraged. Pairing up the architect with other developers in pair-programming will help share the knowledge and gives the architect an opportunity to set the coding standards.

Write interfaces and couple them with test cases. This is a great way to ensure that the code that is checked in will actually perform as it should as it would be independent from the development cycle. There are a few mock APIs that will help this approach. Naturally test-driven development is highly recommended.

The Test Manager

Understanding both the requirements and the problem domain is critical to the success of the Test Manager, and the project.

Requirements will be written badly at times. It is therefore important to hunt down the Product Owner and flesh out these missing pieces. Ensure that each tests conducted is repeatable and well documented. Ideally, automated testing is highly recommended.

A creative, technical, thorough and methodical Test Manager might be hard to find. Ideally you would want a person that is an expert in the domain of your application and have a knack of finding bugs in any system. The scope of the system must extend to that of the customer setup and OS/hardware variation.

The Scrum Master

The Scrum Master lives to help the team, both resolving any blockers and help run the team on a daily basis. Ideally you want a Scrum Master that has the best interests of the team in mind and is at the same locale as the team. Always remember that the Scrum Master works for the people and this position is not suited for an aggressive tyrannical individual.

For our outsourced project, we rotated the Scrum Master role between the team members in Bangladesh with varying degree of success. We deliberately assigned this role to a promising Junior developer as an attempt to break the hierarchical mold in Bangladesh. This did not work well as the concept of seniority is so ingrained that it backfired with a senior developer threatening to quit because he felt that he was undermined by a junior and that his talent was not nearly recognised. Naturally we also tried assigning this role to this particular senior developer but his style was so tyrannical and turned the role of Scrum Master into a mini authoritative dictatorship.

Scrum Master should challenge the Product Owner. Ensuring that the team can finish all the tasks in a given sprint is important. Nothing is more demotivating than constantly pushing sprint backlogs to the next. In stark contrast, nothing is more empowering than being able to finish the sprint backlog plus additional tasks.

One difficult aspect is dealing with bug fixes. Bug fixes can interrupt the whole sprint. That is unavoidable. However, scheduling a couple of bugs each sprint will help drive down the bug lists. A zero-bug policy is admirable. Personally, an alarm bell goes off when there is absolutely no bugs in the system.

The Product Owner

The number one advice is to be available for the team. Answer their questions on time and flesh out your ideas clearly and ensure each user story is well thought out. Communication is key. Ensuring that the team understands the deliverables for each user story will improve their estimations and save a lot of heartaches.

Be interested in the technical details. Participate in testing and consider participating in development. Write test cases, unit tests or anything that will help you answer your number one question: Can I release this product this sprint?

Expect a good product demo at all times. Ask hard questions and never settle for anything less than you deserve.

Having a solid release process also helps. Releasing is surprising difficult and challenging. As Steve Job puts it, “Real artists ship.” I also recommend looking at Chrome`s release cycle – every 6 weeks.

Outsourcing and Scrum: our tools, our process, and some pitfalls

Part 2 of the outsourcing series on Bangladesh.

Last blog we touched on the difficulties in hiring and managing an outsourced team. This blog entry will highlight the tools we used, our processes and some of the pitfalls.

Cloud everything

Due to the time difference and the distributed nature of outsourcing, solid communication channels are critical. The general lack of stable infrastructure in Bangladesh meant that we could not have tools hosted there due to the high risks of down time. Furthermore, power outages would frequently plague the Dhaka office until a backup generator was installed.

We used Google for our emails and documentation, at times Dropbox. We used Jira Studio, particularly Jira, Confluence and Greenhopper for bug tracking, Wiki, Scrum tool respectively. In addition, we use Balsamiq and Gliffy plugins. The Jira Studio packages seamlessly integrates with our Google accounts, which made access control easy. The one thing I loved about Jira Studio is that all the tools are integrated; this includes our source control system. Note that Jira Studio is now migrated to Atlassian OnDemand.

Github is where we store the code. It allows for local cache copies and caters for your very own push process. i.e. Setup a local git repo in Dhaka, team pushes there. A pull request can be submitted upstream and reviewed for example. It can be as simple or as sophisticated as you want.

For sprint demos, we used Webex and TeamViewer for remote access.

Last but not least, Instant Messages and video conferences such as Skype or GTalk was very useful. Did I mention that Voice-over-IP is blocked in Bangladesh? One needs a government permit to get through the great firewall of Dhaka.

Planning and running sprints

Before any sprint planning occurs, the team needs to agree on a “definition of done”. This is the notion that a task is deemed complete. The team needs to come up with this themselves and agree to it. For example, unit testing, documentation and compile-error-free code is pushed to repo as part of the definition of done.

For this project, requirements were written as epics initially, then broken down in user stories. Each user stories are estimated in user story points by the technical team, as well as attaching a business value from our steering group.

Each user story is then further dissected into into technical tasks and estimated in man hours no more than 2 days worth of work. A user story is completed when all associated tasks is deemed complete.

The product owner will prioritise the user stories and provide a product backlog that can be potentially accepted as sprint backlog.

During sprint planning, we used an online planning poker provided by Mountain Goat Software and each task has an initial estimate and a remaining estimate field. These two fields allows us to get a good overview of the burndown and thus the associated velocity in each sprint. Note that an estimate is only accepted if it is a unanimous decision. You will be surprised how people will come to an agreement eventually.

With this approach, you will get burndown in user story points, business value and man hours. The benefit is that after a few sprint, you will get a sense of the complexity of a user story through user story points, and the team`s general performance via man hours.

At the end of each sprint, both a sprint demo and a retrospective is conducted and any unfinished user story is pushed to the following sprint. Note that re-estimation is not performed on delayed user story. In fact, re-estimation is something I do not recommend at all. For example, it is a known fact that estimation is quite inaccurate in the start of any project. Not to mention that there will be a varying degree of competency and perhaps confidence level. As the team progresses, estimation becomes a closer reflection of the complexity of the task at hand, as well as team`s proficiency with the problem domain. Thus the estimation will converge as individuals` own competency improves. In order to fully illustrate this and correctly reflect the increase in velocity, the old crappy estimates must remain. If the project is intended to be very short, then re-estimation *might* make sense.

Sprint demo is the chance where the team can really shine, or fail miserably. Though the Scrum Master should try to protect the team, if the sprint is faced with a ton of road blocks, it is inevitable that the demo will not be their proudest moment. However, that should improve with time. The Scrum Master should be the best communicator in English and host these demos. Anybody from the organisation can attend these demos and encourage them to do so. I have heard that Google often wheel out cake and coffee during sprint demos to set a celebratory tone. And indeed it should be a celebration.

At the end of each sprint, the product needs to be in a shape where it is potentially releasable. This is extremely important as I believe it is the central concept of any agile processes, particularly Scrum. Even if the product does not have a packing or release process, you can still convey to the team that test users needs to be able to check out the code and run the program via some simple scripts. Being able to potentially release at any moment is critical to the success and pacing of the project.

Some pitfalls

  • Estimation. Some team members estimate in perfect days (7,5 hours without any interruption), some include lax time in their estimates. The unanimous estimation aims to find a balance between the two. In time, the team itself will understand and identify correctly the difference between a 2 hour vs 8 hour tasks.
  • Business value estimation is of no use to the business. This is a typical case where an idea is good, but have no real life use usage. Establishing a steering group to iron out these type of features is great to avoid erroneous requirements will hopefully ensure the invested features are with the support of marketing and sales. Once this becomes a routine, showing how much business value deliver per sprint is as easy as looking at the burndown.
  • Inherent hierarchies in Bangladesh. There is an intricate and ingrained notion of hierarchies in the Dhaka team. An interesting observation for me is that a junior engineer cannot be seen having a cigarette when a senior engineer member is in the vicinity. The definition of a junior is merely somebody who has joined the company later, or is of a younger age. Nothing to do with their technical skills. To further exacerbate this symptom, the junior is rarely seen correcting the seniors. This is a huge problem because I would like the team to operate in a flat hierarchy, where ideas and innovation can be freely discussed. There is not easy cure for this as it is part of establishing a local company culture that promotes innovation and discussion, while leaving the old world baggage behind. Our approach was to build a good team rapport and encourage the juniors to speak their mind. One last suggestion is to talk to the juniors directly on a 1-1 basis to find out their thoughts and suggestions. This is quite time consuming of course, but it can be rewarding and often serve as an early indicator if there is something fishy going on with the team.
  • User stories are vague and thus form a horrible basis for requirements. This is the general pitfall of Scrum, not particularly an outsourcing issue. Establish concrete tasks and implementation based on an idea is never straightforward. A vision can be as ambiguous as “As a sysadmin, I want to create a user in this system, so that this newly created user and login and work with the system.” This is a typical user story that any CRUD application will support. But what does that user story really entails? How much work is this? How much business value does this actually give? These are questions that both the team and the steering group will need to iron out for themselves. However, I cannot recommend the use of condition of satisfaction enough for user stories. Be as meticulous as possible when writing condition of satisfaction. Your QA will thank you. If you are the borderlining the formal methods type, then throwing in a UML design methodology would not hurt. It will bolster the understanding of both the business requirements and the implementation itself.
  • The team used powerpoint slides for their sprint demo. This is generally not encourage as the idea of having a potentially releasable product is obviously not met. However, there are at times where this is perfectly ok. I encourage good documentation throughout the development cycle and if extracting power point slides from a few wiki pages will do the trick. So be it. Be sure to not make this a habbit.
  • Certain tasks such as refactoring will render the product in a potentially unshippable state. Create a new branch and merge it back to the release branch is your solution. No excuses that a product cannot be shipped.