When you just want to design UX/UI, code and then sleep…
That is what you can expect at a #Girlcode Hackathon (and some food and energy drinks every now and again).
This year’s Girlcode Hackathon (#GirlCodeHack) took place at 22 on Sloane, Bryanston, Johannesburg and it was an absolute blast.
From apps that give you more insight on tertiary education, to apps that educate you on recycling in your city, to water saving games - all designed, developed and finished in 24 hours. Who said ladies can’t code and UX like a boss?
The 17 United Nations Sustainable Development Goals (Image below) of which we had to choose one or more, are the problems we had to solve.

Looking at these goals, you do tend to get carried away with ideas. When my team and I sat down to discuss a goal we could solve, Paballo Moloi (Pabi) mentioned the waste issue we are currently facing in Johannesburg, which led us to ‘recycling in your city’.
Recycling does not only cover Goal 11, Sustainable cities and communities but also; 6 - clean water and sanitation, 7 - affordable and clean energy, 13 - climate action, 14 - life below water and also 15 - life on land.
Our solution, recycling, led us to create an app, Greenly, that allows you to become more educated around materials that can be recycled and which cannot. You also get all the collection and drop-off points in your city where you can recycle, but not only do you just recycle, you also get rewarded for your recycling contributions. Throughout recycling, whether it is through a collection service or whether you drop off, you will receive a QR code for each time you recycle, the QR code will give you points and as they accumulate you receive vouchers from certain retail partners in South Africa, whether it is a R100 petrol voucher, to R50 off your next grocery purchase.


I started the UX and UI of the app that was later developed by Pabi and Siphokazi Fikeni. Due to the time constraints we only chose to do an Android App and website.
Saturday morning as Pabi and Siphokazi started the Android development, I started building our website. The website gave more information regarding Greenly and also included links to the App stores for down-load. In between the day we had to give elevator presentations to say what we are up to, our progress and goals.

We then also had occasional breaks in between as well as breakfast, lunch, dinner and midnight snacks. The most challenging part was getting through the night, as we were in a venue with a semi-open roof, but myself, Siphokazi and Pabi made a plan and moved to the cafeteria and continued our coding and UX-ing till the early hours of the morning.
With a few power naps in between, we had time until 10:00 on Sunday morning to finish the whole project and get ready for the judging stages.
We had five minutes to present to one of the four judging panels, thereafter the four panels of judges got together and selected their top nine.
We are proud to say that Greenly made it to the top nine! (YEY! ?)
The top nine then had to present again, but this time to everyone and a panel of three judges. After all the teams presented, the judges made their decision for their Top 3 and the winners were announced.
So after 24 hours of coding, UX and UI design and some HTML and CSS we are proud to have ended up on the top nine. (And yes, we went home and slept and slept)

Thank you Pabi and Siphokazi, it was a weekend to remember - You are the best
By Willem Botha, DVT
With the ever increasing need for software development teams to react faster and deliver quicker solutions to problems, agile has become an essential framework to follow. That said, what is the role of the Business Analyst (BA) in an agile world and is the BA still needed as part of the team?
Let’s start at the beginning and go back to the basic definition of business analysis. According to the International Institute of Business Analysis (IIBA), a BA is a liaison among stakeholders to understand the structure, policies, and operations of an organisation, and to recommend solutions that enable the achievement of goals.
Thus the BA’s role is not centred on software; it is about suggesting solutions to business problems and enhancing processes. Software can be part of a BA’s recommendations which a stakeholder would then vet and forward on to a product owner for detailed evaluation as a product enhancement.
In agile when we are talking about a BA or agile BA, we are typically referring to the technical BA when software was part of the recommendation already.
Does the agile BA exist?
Let’s have a look at the characteristics of an agile BA according to the agile manifesto:
- Adaptability: Everyone associated with agile must be adaptable. However, the traditional BA has always needed to adapt to the business process, software development process or even a lack of process.
- Goal Oriented: The goal is to add value to the organisation by solving business problems. This is true for both the agile BA as well as the traditional BA role.
- Innovation: The agile BA, as well as the traditional BA, is looking for new approaches to solving the business problem and improvements to the business processes in which the problem exists.
- Leadership: Being an agile BA or traditional BA means taking the lead in providing solutions to business problems.
- Empathy: The BA deals with the business sponsor, customers, users, solution team, technical personnel and management. Both the agile BA and traditional BA need to exhibit empathy and understanding for all these roles.
- Business Oriented: While the agile software development team is focused on the technological issues of producing working software every two weeks, the agile BA needs to provide the business justification. This has always been true for the traditional BA.
- Anticipation: The agile BA, as well as the traditional BA, must be thoroughly familiar with the problem domain, the business area in which the problem exists and to anticipate positive and negative impacts to other areas of the organisation.
Based on the characteristics listed for an agile BA we can see that there is clearly no difference to the traditional role played by the BA. So if the agile BA does not exist, do we need the business analysis role in agile?
The answer is a definite yes! But, why am I saying this?
Let’s look at what the most successful agile teams have in common:
- Everyone in the team understands the “Why”.
- In the agile world, the BA needs to manage the communication channels with business to understand “why we are working on something.”
- The BA needs to foster a shared understanding, thus a two-way communication flow between development and business.
- Teams can make faster decisions by getting answers quickly.
- With distributed teams where product owners sometimes oversee multiple projects, the agile BA understands the product vision to provide the answers to questions from the teams.
- On smaller teams, the product owner and agile BA role are played by the same person. However, the focus is still on clear communication to all team members.
- Although the BA role might not exist in the agile team, the skills associated with a BA is still needed.
- In smaller teams the product owner may have the required BA skills, making the BA role redundant. That said, the product owner role is usually played by the BA.
- In bigger teams, the agile BA provides the detailed requirements for the different product owners.
- The development team still needs someone to take the lead in analysing business requirements and facilitating the process with business.
- Keeping the noise away from the team and providing clear prioritised work for two-week sprints.
- There’s still a need to facilitate requirement sessions and documenting these requirements clearly.
- Where detailed requirements are necessary, documentation needs to be based on a set template for the team following Unified Modeling Language (UML) standards.
- The team decides when detailed requirements are necessary. However, documenting the business requirement is still required for new members joining a team.
Now if we are saying that the role of the BA might not be needed in an agile team - but only the skills associated with the role, are developers able to play this part in the team? I asked the development community I work with to provide me with answers to this, and it was clear that it depends on team dynamic and the size of the project.
Team dynamic
- If the team has dedicated developers, then they cannot play this role. They have to wrap their minds around difficult technical concepts. They will not be thinking in abstract or general terms and will be busy with the specifics.
- A representative for the business requirement is still needed. Someone must have a clear singular focus on the business need and guarantee that this prerequisite is solved and achieved.
- Sometimes if not done correctly, developers will solve problems that do not exist or invent their interpretation of the business requirement.
- If you have a team of agile people working toward a common goal, where each person does what is best for the project and team at any given time, then yes, the same person who writes code can also perform the function of business analysis.
Nature of the project
- With bigger projects, the role of the BA is better suited for requirement analysis and documenting these requirements in advance, with the development team left to focus on the work in the current iteration.
- Conversely, there are smaller projects where the development team could easily just sit with the business owner and understand the full scope of what is needed.
Business analysis should not be focused on software thus falling outside of the agile process. The notion of an agile BA is not new; it is still the traditional role played by the BA. Moreover, once software has been identified as a solution the BA or technical BA role is still needed in the agile team.
The core principles of the BA role still exist and are needed by the team. Agile has merely freed up the BA to be a BA, instead of a technical BA. These core principles are:
- Facilitate communication and understanding.
- Set team objectives per iteration.
- Fill the role of the business owner or Product Owner proxy
The need for quality analysis in a world of increasing change and technological complexity is high. The role of the technical BA does not have to be a particular person. However, the responsibilities of the role should not hamper delivery from a development point of view.
Agile has also changed the way the BA plays his or her role. The amount of analysis has changed - BAs only do what’s necessary, ensuring that there is no waste in the analysis process.
Focus on T-shaped skills
According to HRZone.com, T-shaped skills describe specific attributes of desirable workers. The vertical bar of the T refers to expert knowledge and experience in a particular area, while the top of the T refers to an ability to collaborate with experts in other disciplines and a willingness to use the knowledge gained from this collaboration.
What does this mean for the business analyst? It means being more aware of the customer journey; what problem needs to be solved, why business needs the product and ultimately how customers will use the product.
Finally, influence the team dynamics by working closely with the product owner, development team and business to help establish a shared goal.
At the end of the day, it is the goal and not the role that is important. It is also clear that the business analyst has an essential role to play in an agile world.
Account Manager – it’s a common title in our industry, and yet so often means very different things to different organisations.
Some account managers mainly focus on sales, others consider themselves project managers first and foremost. Some double as IT advisors, while others spend all their time nurturing customer relationships and keeping customers happy.
At DVT, an account manager is all of these things. But more importantly, the skills it takes to become a successful account manager have less to do with technical proficiency and more to do with the ‘softer’ skills that are critical to every single aspect of the role.
In our fast-paced, highly competitive industry, the human side of the business too often plays second fiddle to the technical. But as we seek to help our clients digitally transform their businesses to better compete and succeed, the process is as much about the human side of change and growth as it is about crunching numbers and coding software.
The following steps are used to guide the development of any successful account manager in our business, and could likewise be valuable to yours.
1. Working to a set of values
Every business, DVT included, has its own set of cultural values, honed over time and passed down to successive employees through recruitment and training programs. These values cover a range of different aspects, describing how we conduct ourselves personally and professionally. For example, ‘doing the right thing’, ‘making an impact’, keeping it simple’, and ‘work-life balance’ are all shared values common to the company culture and its employees. If you haven’t defined your values as a company, you can’t expect your account managers to follow them.
2. Emotional intelligence (EQ)
Perhaps the most important part of an account manager’s job is managing people. In fact, if you substitute the word ‘account’ for ‘people’, you’d get a good idea of how many account managers spend most of their days. Managing people requires a very different set of skills to managing numbers or IT systems, and yet too many account managers are only trained for the latter. Knowing when to push back, or when to give more; being able to read someone’s expression and reaction, their body language and the tone in their voice; and having the ability to think before speaking – these are just some of the critical skills that make up an account manager’s EQ.
3. Understanding culture and unique conversation style
No business relationship is ever the same. The way we speak with one person will always differ, even if only slightly, to the way we speak with another. This doesn’t necessarily come down to our level of seniority or skill, but rather to intuitively knowing (or learning) the best way to connect with a person based on their personality style, the history you have with them, or the way they treat you at face value. Taking the time to learn and understand how to speak to different people is a stepping stone to building lasting relationships with them.
4. Getting personal with consultants
We’re all pushed for time, and therefore making time to get to know our consultants is often last thing on our daily To-Do list. However just a little effort made to spend time with each individual on a regular basis to get to know them, and for them to get to know you, builds a rapport that encourages trust, openness and honesty. These qualities in a working relationship help keep consultants engaged and retain staff.
5. Understanding talent acquisition and retention
DVT recruiters make excellent account managers, not only because of the recruitment cycle they go through to on-board new consultants, but also because of the interview and assessment processes our consultants go through with our clients. Recruitment in the IT industry can be highly competitive given the skills shortage in South Africa, which is why it’s important to learn to connect to consultants on a personal level, and to constantly stay informed about their relationships with clients. That way, any ‘issues’ are identified and resolved before they escalate, and the cycle of trust is constantly restored.
6. Project management
This may not appear to be a ‘soft’ skill like some I’ve already covered. However, an account manager is, at some level, also necessarily a project manager. DVT account managers work very closely with each practise and competency team, along with several other teams: development, business enablement, data/analytics, testing and automation, and so on. To work effectively and equally with each team means the account manager must always be proactive, communicative, transparent and organised. Involving multiple teams on a national basis while managing an important assignment requires a high level ‘people’ project management skill.
7. Knowing when to say ‘No’
It can be daunting to say ‘No’ to a client (or a colleague or a boss for that matter) but it’s a skill that needs to be learned and used effectively for successful account management. It’s even harder to say no to new business, especially if you are measured and rewarded for the business you bring to the company. But if taking on new requirements from existing clients – or business from new clients – that is unrealistic, or compromises values, or negatively affects delivery standards on other projects, ‘No’ is sometimes the only safeguard. Using measurement metrics helps to identify which opportunities are worth focusing on, but the ‘art’ of knowing when and how to say ‘No’ is often just as important as the science.
8. Thirst for knowledge and personal development
There is an overwhelming amount of information available to us as account managers, and it’s constantly changing. It’s not good enough just to know what our company does; we should also want to know the trends and topics of industry. This improves our confidence and encourages like-minded conversations among peers and clients. As account managers we need to set aside time every day to upskill, learn and improve – so it helps if we have a natural learning instinct, or learn to develop one.
9. An Agile mindset
Agile is a word synonymous with DVT on a business level, but it’s also a critical component of the very human skills we instil in our account managers. As account managers we understand better than most how direction, goals and purpose constantly change, both internally and for our clients. This means that we don’t always have a clear view of what’s coming, regardless of how much planning we do. We therefore need to learn how to be adaptable and flexible every day, to be open to new, as-yet untried and unproven approaches, but most of all, we need to accept that there will always be a mix of achievements and missed opportunities in our line of work. If managed properly, the ups and downs make us highly resilient, humble and motivated to ensure continuous improvement in our way of work.

In this tutorial we will learn how to authenticate using google sign-in. Google enables us to register/sign-in to our apps using different social accounts such Facebook, Twitter or in our case Google. Let’s get started!
Android studio project
Create a new Android studio project and name it “FirebaseAuthGoogle”. For the Company domain use “myricseptember.com” and ensure that the Include Kotlin support checkbox is selected.

Leave the minimum SDK as it is and click Next. Select “Empty Activity”, than click Next. Name the activity “SignInActivity” than click Finish.
Create a firebase project
The first step is to create a Firebase project within your Firebase Console. Click on Add project:

Name your project “FirebaseAuthGoogle”. Once you’ve given your project a name, read and accepted any terms and conditions, then click the ‘Create project’ button. Once done you should see the following screen indicating that the project was successfully created.

Click the continue button where you will be taken to the welcome screen. On this screen you are given the option to create either an iOS, Android or web app. We are creating an Android app so click on that option:

Another window will open requesting some information relating to your application. Fill in the package name “com.myricseptember.firebaseauthgoogle” than add your SHA 1 key. If you don’t know how to get your SHA key follow these steps:
- With Android Studio open, click on the Gradle menu on the right to open it.
- Open the folder structure as follows: FirebaseAuthGoogle -> :app ->Tasks->android -> then double click on ‘signingReport’

Note: if the packages are not showing in the gradle menu just click the refresh button:
A window will open at the bottom from which you can get your SHA1 key:

Note: Remember to select the app option in your Android Studio project once you have your SHA key, see below:

Add the SHA key and click On Register app:

Download the JSON file and place it within your android app as indicated by the arrows then click ‘Next’:

Once you get to the screen below just click next since we will be adding all the necessary gradle dependencies at a later stage. Also after the Add Firebase SDK screen Firebase will try to check if the app has made contact, just click on ‘skip this step’:

Great! Your application is now connected to firebase, but we still have some more work to do. Let’s get to it!
Enable Google Sign-In on Firebase
In your Firebase console on the left click on the ‘Authentication’ item. From the tabs select ‘Sign-In method’ to open the window below. Select the following:

Enable Google Sign-In in the top right corner. Also provide a ‘Project support email’ and click Save.
Add Gradle dependencies
Next, go to your Android Studio project. To enable social authentication we need to add some Firebase dependencies manually. It is import to use the latest Google Login SDK version which you can find here.
Here you’ll find the latest Firebase dependencies.
Open the project level Build.gradle :
Then add the following dependency:

Next open the Module:app level gradle dependency:

And add the following dependencies:

Once all these dependencies have been added, Android studio will require you to sync the project. This will download all the dependencies from the internet and will require you to have an internet connection.
Note: It is very important to ensure that you have “Google Play Services’ installed. You can do so by clicking on ‘Tools’ than selecting ‘SDK Manager’ as seen below:

After clicking on ‘SDK Manager’ the below window should open. Select the ‘Google Play Services’ checkbox and click apply. This will ensure that Sign-In works as expected on the Google Emulator as well.

Create a simple UI
Next we will create a simple UI with a single button in the middle of the screen. You can make your UI pretty but for demo purposes we are going to keep things simple.

Add the following to your “activity_sign_in.xml” xml file:

Since you need to connect to the network to authenticate with Firebase you will need to add the internet permission to your AndroidMenifest.xml:

Integrating Google SignIn
Within the SignInActivity add the following variables for the GoogleSignInClient and GoogleSignInOptions.

Next add the following method to your code. The method is used to request the user data required by your app such as the users’ ID and basic profile information, email address and Id token. Call this method in your OnCreate() method.

Add the setupUI() method to set up the OnClickListener for our login button. This method gets called in the OnCreate() method:

Next, we add a singIn() method which will be called when the user presses on the log in button. The user will be prompted to select an authentication account. The signInIntent is used to handle the sign in process and for starting the intent the startActivityForResult() is used.

Once done the onActivityResult() is called in which the selected google account is retrieved and sent to Firebase for authentication.

Note: the implementation for the firebaseAuthWithGoogle() method will be discussed below.
The authentication with Google step is now completed. Next we need to authenticate with Firebase. Declare an instance of the FirebaseAuth object.

Then in the onCreate method, get the shared instance of the FirebaseAuth object

After a user successfully signs in, gets an ID token from the GoogleSignInAccount object, exchange it for a Firebase credential, and authenticate with Firebase using the Firebase credential:

Note: The HomeActivity will be created soon
To avoid the need for the user to sign in every time the app is launched it would be better to check if the user is signed in already. This can be achieved by checking if the current user is already signed in from within the onStart() method:

Create a companion object to open the SignInActivity via intent.

Great! Everything for authentication is set up. Next we just need to create a second screen (HomeActivity) to which we will navigate once the user is successfully authenticated. You can use this screen to retrieve and display the current user’s information from the Firebase database, but that is out of the scope of this tutorial. We will simply display some text congratulating the user for successfully signing in and have a log out button at the bottom.
Home Screen
Create an Activity called HomeActivity. The activity will look like the screen below once done:

The XML for activity_home.xml should look something like the below:

Within HomeActivity add the setupUI() method which will be used to set up the click listener for the sign out button. Call the setupUI() method within your onCreate() method.

Next create the signOut() method which will be used to sign the user out of the application.

Finally create a companion object to to open the HomeActivity via intent.

We’re Done! Let’s run the application and celebrate our hard work.
Conclusion
In this article we have built a simple application that makes use of Google authentication. Firebase is great and there is much more you can do with it. I will be posting more Kotlin articles and will be using more of Firebase. I look forward to your feedback and would advise you to take a look at the repo.
Thank you for reading this article and follow me on Twitter and on Medium for future articles.
Article also published on Medium.com.