Growing Agile is a partnership between Karen Greaves and Samantha Laing focused on helping companies and individuals be agile. They provide coaching, support and training to help you find the right path for your organization. Their goal as a company is as simple as their name – to keep growing agile.

Here’s what they had to say about their visit to Chillisoft.

A dojo refers to a place of training it literally means “place of the way”. A coding dojo is a place where developers come to hone their skills through practice and repetition, whilst learning a thing or three about TDD.

A Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each practice. The intent behind code kata is similar, each is a short exercise (perhaps 30 minutes to an hour long). Some katas involves programming, which can be coded in many different ways. Some are open ended, and involve solving the issues behind programming. The theory is that if you practice a common technique regularly over time the actions will become natural and automatic, you will have muscle memory.

Our Operations Director, Brett Powell, who has been a pioneer of TDD in South Africa, ran the dojo. He has been a vigilant proponent of the thought discipline of lean development, implementing and continually experimenting with its core ideologies and beliefs. Through the years this paradigm of continuous improvement and Iterative Development has been adopted by Chillisoft and is a central pillar of our culture and development domain. Testament to the success of this process is Chillisoft’s impeccable track record and our ability to deliver quality software to its clients.

Here’s what some of the developers had to say about the Dojo ;

“Training was very helpful and helped me become much more familiar with TDD”  Terence Naidoo Developer SA Homeloans

 “I have learnt a lot. Keep up the great work” Craig Van Niekerk  Developer at Interactive Solutions 

“A perfect mixture of theory and practice” Craig Peter, Developer at IUA

We will be holding many more Coding dojos in the near future, so stay tuned for updates.

The days of 26^th to the 28^th September saw Chillisoft attending the 7th Annual GovTech conference. The conference is South Africa’s premium public sector ICT knowledge-sharing and learning event and Chillisoft was very excited to be part of a host of international and local companies showcasing their products and technologies in Durban’s International Convention Centre.

The event’s chosen theme was ICT Collaboration, with a focus on how the collaborative use of ICT can assist the delivery of citizen-centric services. The Chillisoft health product vision is well aligned to this cause, and our stand presented technologies that can improve efficiency in the health sector and subsequently improve patient care services.

On display was our current pharmacy dispensing software, ReMed, and add-on prototypes to the application. Much interest was displayed in the simple touch screen interface, the rapid medicine label printing, the 2d-barcoded patient identity cards, and the barcode scanning functionality which streamlines the search for patient data and prescriptions. Patient cards in particular offer a unique approach patient information management as they can be used throughout the health network and assist the upstream and downstream referral of patients between institutions.

Also inviting attention was our prototype for a RFID medical stock management solution; this generated the question on if a similar technology and solution could be used in other government departments. With the Chillisoft can-do approach to delivering quality software, the answer is simply, yes, yes our prototypes are a proof of concept and our technologies can be tailored exactly to specific needs in a variety of fields.

This past Wednesday, the Durban Agile User Group assembled at the SQS Offices in Westville.  The topic for the evening: “Writing User Stories”.  I joined a number of my colleagues from Chillisoft for the presentation and to meet some of the like-minded Agilists from in and around Durban.  Ajay Mohanlal from SQS, the guest speaker for the evening presented to a full house.

Ajay’s presentation focused on how to define a user story.  He started out by giving a fairly comprehensive definition of what a user story is and what the benefits of writing user stories are.  One concept here, that I found very useful, was that a user story should be considered a placeholder for further discussion.

Although the presentation seemed to fly by, on reviewing my notes after the presentation, Ajay actually covered the topic fairly thoroughly in the end.

Ajay’s presentation certainly inspired some fairly heated debates.

Two topics that seemed to strike a chord with most people were:

• How to correctly estimate a user story
• The use of acceptance criteria

Estimating user stories was somewhat outside of the scope of the presentation, but it appears that the general consensus was that planning poker was the most common way to estimate the size of the task.

The use of acceptance criteria to define “DONE” in a user story was the most hotly debated point.  A number of attendees felt that the acceptance criteria, as shown in a sample user story template that Ajay presented, made the user story look very similar to a traditional requirements document.   There was an argument that the developers working on an agile team should be experienced enough to work out the acceptance criteria outside of a planning meeting and present a finished story themselves.

Since then I have done some reading up on the subject to clarify my thoughts.

I think there needs to be an amount of flexibility in how you choose to define your user stories as no project is exactly the same.  Projects and teams will vary in size and structure.  Sometimes project teams will be split between locations and sometimes the project owner will only have limited time in a week to commit to the project.  With this in mind having a well define meaning for “DONE” is important.  There is a concept of “Conditions of Satisfaction” which is generally defined by the all stakeholders and is used to define what “DONE” looks like on a project.  Acceptance criteria on the other hand are generally defined by the agile team for each user story either during the planning meeting or immediately after it.  The acceptance criteria should aim to cover the business rules and no more.

After the presentation most of the attendees remained behind for a drink.  For me this was a great opportunity to catch up with some other people in the software development industry and to talk about our experiences and approaches.

Thanks to Kim and Gennine from SQS and Chris from Chillisoft for organising another successful Agile event.

Hey all you Capsicum Crusaders, you’ll be interested to know that Chillisoft is living up to its name and spicing up the software development world. Brett Powell, our Operations Director is down in Cape Town this week imparting his wisdom on all things agile, test driven and just generally AWESOME. Brett will be lecturing to a class of post grad IS students, giving them some insight into latest methodologies and best practices of quality software development.

Brett has been an evangelist of the agile movement since the early days, when the Agile Manifesto was still a quirky idea in the software development underground. Since then he has been a vigilant proponent of the thought discipline of lean development, implementing and continually experimenting with its core ideologies and beliefs. Through the years this paradigm of Continuous Improvement and Iterative Development has been adopted by Chillisoft and has become a central pillar of our culture and development milieu. Testament to the success of this process is Chillisoft’s impeccable track record and ability to deliver quality software to its clients.

As a leader in our domain, it is Chillisoft’s belief that a relationship with education institutions is integral as a mechanism by which our wealth of pragmatic and practical experience may be shared with those entering into the field of software engineering. Similarly it is precisely these new minds that are the most valuable resource for innovation and breakthrough insight allowing old systems to give way to new and better ways of doing things. Together, dynamic but steady evolution may happen and it is this symbiosis between knowledge and inspiration that we hope to nurture.

We will be sharing some of Brett’s content soon on our website, so watch this space for more!

ReMed is a software solution purpose-built for managing the dispensing of chronic medication.ReMed improves the efficiency of state pharmacies and the ability of pharmacists to provide high quality care for chronic patients.

ReMed is specifically designed for the public health sector for use in primary and secondary public health institutions (i.e clinics, community health centres, district hospitals and provincial hospitals).

ReMed has been developed to operate within the unique constraints of the South African public health sector:

•   There is a dire shortage of pharmacists so it is critical that pharmacists are optimally productive.
•   The dispensing workload is constantly growing because of the increasing numbers of chronic and ARV patients.
•   The majority of public health institutions have a limited extent of computerization and Internet or intranet connectivity
•   Software solutions designed for the private sector and international markets do not understand the unique challenges facing public health institutions.
•   The transition towards electronic health records begins by unlocking efficiencies through task automation and process systemisation
•   Solving real, urgent operational problems is the best way to gain staff buy-in and ensure a successful implementation