Hi Durban Agilists,

Can you do Agile without TDD?

As we head into spring and leave the cold weather behind us, we’re gearing up for our next AgileSA Durban gathering which will be held in a few weeks time on Wednesday 5th October. This event will focus on TDD with the theme being “Can you do Agile without TDD?”.

Brett Powell from Chillisoft will be doing an interactive presentation on Agile & TDD and what it means in an Agile development environment, after which we will proceed with an open discussion on the topic, allowing the chance for experiences to be shared and questions to be explored.

DATE: Wednesday 5th October 2011

TIME: 5:00 for 5:30pm

VENUE: SQS, Ground Floor, Technology House, 29 Salisbury Avenue, Westville, 3630 South Africa

FOCUS: Can you do Agile without TDD?

Hi Fellow Durban Agilists

With a fabulous Easter break behind us we are looking forward to our next Durban Agile gathering which will be held in a few weeks time on Wednesday 25^th May.  This event will focus on RETROSPECTIVES.  Following a brief overview from Kim Johnston, from SQS, covering the purpose of retrospectives in Agile and what they are all about, we will proceed with an open discussion on the topic, allowing the chance for experiences to be shared and questions to be explored.

** Click here to register for this free event **

To flex our collective knowledge a little we will then run a retrospective as a group, where we will look at our Agile user group and the year that has passed, utilising full retrospective techniques to establish what has worked, what has not worked, what we have achieved, how the group feels about our user group and then what we would like to see the group doing going forward.

WIN WIN WIN …

Additional to this great line up, we have a very exciting lucky-draw competition:  Peter Hundermark from Scrum Sense will be running a Certified Scrum Master training in Durban on 7/8 June 2011 and he has very generously offered to give away a seat on this training for our lucky draw at this May event!  This prize is worth R9700!  For more information on this course please visithttp://www.scrumsense.com/training/csm .  To stand a chance to win this amazing prize, bring along your business card, or fill in a form on the night, and the winner will be drawn at the event.

SQS is also very kindly sponsoring some very delicious snacks and beverages, so there will be refreshments to keep you going.

To summarise the details:

DATE: Wednesday 25^th May 2011

TIME: 5:00 for 5:30pm

VENUE: SA Home Loans, 78 Armstrong Avenue, La Lucia, Building 4 Basement Venue

FOCUS: Exploring Retrospectives (+ an awesome lucky-draw)

RSVP: Click here to register for this free event

We look forward to another great user group gathering and hope to see you there.

Rosalyn Charlton, and the Durban Agile SA Committee

This event is sponsored by:

For those who like to do so some interesting reading, download this PDF

By Rosalyn Charlton

March 2011

Our Durban Agile user group kicked off 2011 with an in-depth open discussion on some concepts that lie at the very heart of Agile, but which often pose the greatest challenges to Agile teams; these being Collaboration, Swarming, and Pair Programming.

Interestingly, although collaboration is a core concept of Agile, it is never well defined by the Agile community in any distinct form and is often very misunderstood. It is never really clear whether one is “being collaborative” or what it looks like when one “swarms” and whether pair programming is really worth its discomfiture. Hence our selection of these sticky topics for our first gathering of 2011.

With an agenda-free approach, armed only with flip-charts, coloured pens and three willing scribes, the group jumped right in and stirred things up nicely, arriving at some great concepts, ideas, improved understandings, and generally agreed upon definitions. Beyond just the “What Is It” discussions, the group explored in great detail the ever-burning question of “How do we do it”, and through this some great experiences and insightful thinking was shared. I have allocated a greater proportion of this article to discussing the techniques of “Swarming”, as it seemed to be the topic of most contention and greatest need for clarity. It also happens to be my personal belief that it is one of the essential “tricks” to getting Scrum right.

While a lot of ground was covered during the group’s discussions, and these are certainly topics one could discuss at length, I will summarise the outcomes and highlight the more crucial points made by the group, and add my own insights from time to time, if I may.

Collaboration

It was agreed that collaboration was applicable in all industries and environments, but first-hand experience in the group was of course in collaborative arrangements between IT teams and customer representatives.

• Collaboration is best represented by a multi-skilled group working toward a clearly defined common goal, with a mutual undertaking and accountability to the achievement of the common goal.
• On-going and meaningful face-to-face communication is essential, even if this is via video conference tools for remote teams.
• All parties contribute and communicate throughout a project; there are no surprises.
• In Agile IT projects, collaborative teams are comprised of agile development teams and business users or customers, or their appointed representatives, i.e. those who best know the requirements, and those who will implement the solutions.
• The collaborative team is jointly responsible for decisions and solutions, and mutual trust is integral to overall project success.
• In practice, collaboration always produces higher performing teams, shorter times to market, and more accurate “fit for purpose” solutions.
• Collaborative approaches reduce assumptions, improve project communication, and result in higher quality and greater productivity.
• Solutions more accurately reflect the customer’s needs as collaborative behaviour alleviates misunderstandings.
• The classic Agile objective of “Fail Fast” is fully enabled as solutions (and impediments) are assessed incrementally and development direction adjusted accordingly.

Swarming

As peculiar as this practice may sound and seem, and regardless of what you choose to call it, it is undoubtedly an extremely essential Agile practice within Scrum development teams in particular, and was explored within this context. While this behaviour lies at the very heart of Scrum philosophy, it is often misunderstood, or overlooked entirely when teams implement Scrum, possibly for the reason that it is an incredibly foreign approach for development teams to take, and can seem counter-intuitive. In all the teams that have implemented Scrum with ‘swarming’, its benefit is uncontested. Let’s explore further.

• An agile development team ‘swarms’ by having all team members working together on a specific backlog item (eg user story), at the same time.
• Rather than taking on a separate piece of work each, as is customary in conventional development practices, the team tackles ONE item, combines their skills, self-organises, and achieves the solution as a unit in the best way possible.
• Ideally this is the approach: the team selects the highest priority item on the sprint backlog, designs the solution together, breaks this up into tasks to share between them, integrates these respective parts to form the solution at the end, and does not move on to the next story until it is done – as per the team’s definition of done.
• The team needs to first have a clearly understood definition of done.
• This approach ensures that the team delivers distinct, completed and usable items of work within each iteration, rather than numerous half-completed work items.
• A swarming Agile team is given the autonomy to self-organise. The team decides, as a unit, on the best solution and best approach to achieve this solution. This self-organisation results in the greatest possible productivity on any task.
• A high-trust environment is essential, both between team members, and in the team unit by the organisation.
• The knowledge and skills of all team members are contributed to each work item and used to achieve the agreed objectives.
• Prolific and almost effortless knowledge-sharing and cross-skilling occurs in a collaborative team using swarming techniques. This reduces knowledge silos and associated risks.
• The suggested preferable Scrum team size of 7 plus or minus 2 becomes very relevant in this arrangement.
• The team is jointly accountable for every deliverable, and commits to that deliverable as a unit. This produces far greater ownership and rates of success.
• Taking guidance from product owner prioritisation, the team must be permitted to select its work per iteration and commit to these deliverables.
• Greater innovation is encouraged and enabled, and creative problem solving occurs when a team is held jointly accountable and is not constrained by predetermined roles and approaches.
• The team’s sense of achievement is far greater since deliverables are achieved with every iteration, with increased success.

Pair Programming

This topic is so extensive, and diverges in so many directions that it may very well be a good topic for an entire event or workshop. We eventually constrained our focus to the very high-level pair programming principles, and the following points were agreed:

• To most, pair programming simply means 2 developers, one PC, one person typing, the other analysing and advising; in other words, two people working simultaneously on a single piece of code at the same workstation.
• Up to 4 developers have also worked successfully in this manner with great success, still only 1 at the keyboard.
• The roles can be switched as regularly as needed to achieve fresh perspective.
• The different perspective provided by the slightly removed role of “observer” yields far better solutions since the code can be reviewed as it is created.

The benefits of pair programming are hotly debated, since logically placing two people on one task defies productivity. What has been found, however, is the following:

• Statistically 60% greater efficiency is usually experienced in pair programming teams.
• Quality of the code produced is always far better than that produced by individuals alone, bringing huge time savings.
• Errors are spotted immediately; essentially, in-line code and solution review is performed.
• Team members learn improved and alternative techniques through observation and joint participation.
• Costs resulting from product failure and bugs are significantly reduced as delivered quality is dramatically improved.

While it was a common comment that this practice is quite uncomfortable for developers at first, all successful pair programming teams reported enormous benefits and productivity enhancements, which they agreed made perseverance past initial discomfort worthwhile.

Putting it all together

Combining all these ideas and concepts, I have attempted to formulate a hypothetical, yet highly recommended, approach for a scrum team working on a project.

Let’s take a scrum team, comprised of developers, testers, business analysts, scrum master, along with a product owner to prioritise the product backlog. Along with this we have business users (or customers, since these are regarded as the same thing in Agile) who have been identified for their understanding of the business needs.

The scrum team and the business users are jointly accountable for the success of this project. They will collaborate throughout the entire project from specifications of User Stories, throughout each iteration, to final testing and implementation, with the ideal scenario including co-location of all participants. The solution is emergent in this arrangement since there is preferably no large upfront plan or design. In this way the business representatives and the developers ensure that the product being developed meets the real needs of the business every step of the way.

As the scrum team selects from the backlog, and commits to, a set of User Stories for each iteration, they build a sprint backlog that they will swarm on by tackling the user stories (backlog items) one at a time as a team. When swarming, the team will self-organise to determine the best possible solution and the best possible way to achieve it, and collaboratively involve the input of the business users throughout as needed.

The team will break each user story down into smaller tasks, sharing these amongst themselves, trusting each other’s understanding of their collective accountability to the deliverable. To perform this development the team will break into pairs and tackle it using pair programming, thus ensuring delivery of the highest possible quality, reduced come-backs and enhanced productivity on the overall project. Completed tasks are integrated by the team ensuring that the overall solution meets the real requirements of the business by collaborating with business representatives.

Once the solution meets the team’s definition of done, they will swarm on the next user story having successfully produced a distinct and usable increment of business value. This is the ultimate objective of these practices.

It certainly seems to be a shared conclusion that using any, or all, of these practices one undoubtedly achieves greater productivity and team velocity, higher product quality, greater knowledge sharing, a reduction in high-risk pinnacles of knowledge, and engaged committed team members. Ultimately, these practices deliver greater business value, which is the primary objective of Agile.

From our perspective here at SA Home Loans, in the scrum teams we are thoroughly appreciating the techniques of collaboration, swarming and pair programming, as well as the enormous benefits we see at the end of every single sprint. After spending the last year or so working at these practices, and understanding how they work for us, attending this Agile SA gathering gave us an opportunity to share in other teams’ experiences, voice our own findings and approaches, and glean some new ideas as to how we can improve even further.

While it may not be easy to achieve, the effort involved in getting it right far outweighs any effortless alternative.

By Ivor Jordan

Collaboration works! This statement is empirical not anecdotal. Why?

 Well in practicing agile I have been witness to our team successes as a direct result of the following:

 We have well defined singular shared goals that are defined around each task or endeavour.

• Our singular focus is both intra-team and inter-team.
• We have a deep personal commitment to succeed together.
• We iterate and evolve results that are collectively supported and understood.

 I take from this experience that not only does collaboration work but is a corner-stone to agile.  This sentiment was shared by our Durban agile community at our latest meeting, which by all accounts was a successful collaboration in itself.

The well supported discussion touched on topics from remote collaboration to pair-programming to customer collaboration challenges. As a result of this breadth of subject matter shared, we have establish as a community that collaboration has to be actively encourage and lead as it does not naturally occur. Communication and co-operation tend to dominate in our IT industry where collaboration is a learned skill. The singular shared goal and personal commitment by all involved to this goal where highlighted as key to collaboration.

Overall our Agile SA February event was an enlightening and affirming. It was encouraging to see my personal empirical perspective reinforced by so many in our technical community.

Interesting blog regarding the Death Star. They claim it was an agile project.

Here for more info.

Hi Durban Agilists,

Welcome to 2011, and a very AGILE one it is set to be!  We will be kicking off our ‘Agile 2011’ with an open discussion forum on the evening  of 16^th February.  The topic will be:

Collaboration, ‘Swarming’, Pair Coding:  What they are, and when to do which.

The event will take the format of an open discussion facilitated by Rosalyn Charlton, Chris Tite and Adriaan Prinsloo with the discussions centered around these concepts and their definitions, investigate their varied understandings of them in reality,  and share experiences, suggestions and knowledge on the topics and the vital parts they play in Agile teams and processes.

This event is sponsored by: SA Homeloans, Clyral and SQS

Bring along your  willingness to explore, to learn, and to share ideas, and any wealth of information you may currently have or might acquire on the topic.

Venue: SA Home Loans, 78 Armstrong Ave, La Lucia, Building 4 basement venue

Date: Wednesday 16^th February 2011

Time: 5:00 for 5:30pm

Snacks and drinks provided.

e-Logics recently hosted the AgileSA Gauteng event in Centurion on November 24 .

Ushers showed people where to park and pink drinks were served at reception

Jacques Velleman reflected on lessons learned using Agile within the e-Logics software development process and the journey forward for e-Logics. Key points to mention was the successful contribution regarding communication within e-Logics among the team and role-players.

Lionel Bisschoff’s (Mobilitate) talked about Agile from a product owner’s point of view and this was very informative

“I love pot-holes!”

It was also important that the initial most challenging technology problems were addressed first; unlike the easy ones we tend to start first.

Interesting to note that Google Maps and Flickr were used in the technology offering in such a way that I never thought could be possible. This was also part of Mobilitate’s key “Must have” criteria’s and user stories.”

The marketing ladies from e-Logics really did well and the best food and coldest beer was provided. Kaizania also sponsored some good wine and the Chapel Red from Robinson Winery was a definite winner among the wine lovers!

The book review done by Nicky Stapelberg (aka “Trucker” due to his Movember moustache) was very informative and the lessons learned that I remember are: Myths are busted on practically every page, even myths that are associated with lean/agile and it provides 175 solid principles that could make a big difference for almost any product development organisation, from beginners to the most advanced.

“It offers a fundamentally different way of thinking about product development processes”

“flexibility is the result of advance choices and planning”

The downside of the evening was that people had to leave early at 21:30, but the presentation, questions and discussions held during the evening made up for it.

I’m looking forward to the Agile Road Show to be held next year in the first quarter of 2011 and the three cities that will be covered is Gauteng (Jhb/Midrand/Pta), Durban and Cape Town.

Arrie van der Dussen (www.agileacademy.co.za) said that two success factors for this road show are: “It must be free” and, “It must be agile for South Africans by South Africans.”

It is good to know that the Project Management South Africa (PMSA) will also partner with AgileSA in the future.

Further communication will send out regarding sponsorship, business cases and call for papers so watch out the press for more details and visit www.agilesa.co.za.

Dear AgileSA members,

Welcome to 2011, may it be a great year for us all and for the adoption of Agile in South Africa!

2010 was a great year for AgileSA with the establishment of AgileSA Durban and AgileSA Gauteng (still waiting for Cape Town ).

The year was filled with exciting events and the membership and attendance of these events have grown tremendously. What was truly amazing to myself is how many true adopters of Agile there are now in South Africa. This was seen in the involvement of people, the passion they have, the questions they ask and more importantly their willingness to stand up at events and share their wealth of agile knowledge gained through practical experience with others.

Although we had some successes in 2010, we also had some failures. This being Agile, we learn from our failures in order to deliver a better product. This is what 2011 will be about.

Have you joined us on Facebook yet?

As to increase the social part of our community, we now have a Facebook Community – www.facebook.com/agilesa… join us and ask questions, answer questions from others in the community, share successes, share failures, share great books or articles and much more…

That said, we need your help, and very soon…

1. We will allow you to have more input into the themes and topics for events – check back soon

2. We want more people from the industry to share the experience by volunteering to speak at events – please contact us

3. We need more support from local organisations  - yes, we will market you brand

4. We need volunteers to assist us in organizing an AgileSA 2011 Roadshow. The aim, well, to organize a FREE event showcasing the amazing adoption and experience of agile in South Africa. If you may be interested to assist in the organisation, please contact us.

Loads more on the backlog and loads to organize, but I personally am looking forward to a great 2011 agile year!

Regards

Arrie van der Dussen

AgileSA