Theme images by Storman. Powered by Blogger.

Software Testing

[best practices][feat1]






Most Recent

Random Posts




Wednesday, August 14, 2019

How to make your teams deliver fast in Agile

- No comments


What do you think of, when I say the word Impediment. I know most of the agile/scrum teams are familiar with this term.

Agile teams normally fails to deliver fast due to a lot of impediments. Some of these impediments are visible, while most of them are not. Let's try to find out how we can deal with these impediments in our team. 

I want you to think about 5 things that popped into your mind when you here this word - 'Impediment'. Just think about those 5 great impediments you have in your product/project before proceeding to read further. 

You know right when I say this I cannot read your mind and know what you guys are thinking about right now. But my sixth sense says most people when we talk about impediments think about things like a slow or broken machine or a code repository that's gone down or just a lack of resources or skill gaps in your team. Well I am not sure about my sixth sense, if it's functioning well now-a-days but one thing I know is that we tend to forget about all the little things that takes time. Things like waiting for the product owner or waiting for stakeholders to make a decision. We can define impediment as:

"Anything that prevents your team from going as fast as possible is an impediment"
So let's talk about noticing and listing down the impediments. When we talk about agile, Scrum is a great framework to deal with it. 

This third questions is what we are talking about here. Do you think we are answering this 3rd question efficiently and effectively ? I have noticed that normally people tend to mention the big impediments like broken machines, but those small ones we had talked about earlier, those don't get mentioned in that question in a proper way right ? Do you think it's not an impediment to you or not just worth mentioning it ?

I agree standup's are still a good place to notice impediments though if you listen to the language that people use you will get even more attention to the actual impediments of your team. Let me just go through a small standup example. I am trying to mimic a standup conversation happening in one of my team:

Dev 1: I'm busy with the portfolio page on our Web site and I'm still waiting for Vinu to finish the images. I assume he will give it to me before end of the day.

Scrum Master: I really wish we could find a way to do the images faster and I guess we just have to wait till he's done.

Dev 1: Well I'm hoping it's going to be finished soon. It was almost finished.

Dev 2: Ok, I am gonna try to work on the Event page there with Zen. We've got to get that widget working, it's actually not working.

Scrum Master: I think Zen is not available today, He is still working with Fred's team for some quick fix.

Dev 2: Oh, I forgot about that! I guess he's still busy with that. Mmm Ok, Well actually I will find some time to do it by myself then and not take a bit longer.

Scrum Master: Ok

In the above conversation, did you notice some of the words that they used? Some of these words we call them are impediment words. 

Let me explain. See the words given below which is actually there in the conversation above.

These words mean that there are some kind of uncertainty. All of them assuming and waiting for something. And the truth is that if there's uncertainty, chances are high that it's going to slow down the pace of the team.
Next time when you hear these words, what I suggest you do is take notes and write these words down for yourself & take it to your next meeting. Let it be a stand-up or a planning meeting and start to notice if people are using these words. If they do, try to figure out what the impediment behind that is.
Now let's talk about some other places you can look for impediments. We've looked at the stand up and listening to the language of the team using. Now I want to talk about policies and assumptions. If you think about policies, one of the policies the teams usually have in place is the definition of done and they are put in place for really good reasons. But sometimes, they can also be your impediments. 

I know a team who had something on the definition of done that, the architect had to do the code reviews. It was a good intention at that time but that can become a bottleneck if that architect is busy. And at the time of UAT one person has to do the cards reviews as per the Contractual UAT testing and the story can't be done. That might slow the team down and they could look at other ways to solve that instead. 

Assumptions are a little bit more difficult because they're not written down like policies but they can still be impediments and they can still slow the team down. One team I worked with had an unspoken assumption that they were striving for a 100 percent test coverage when they were working with a vendor, but only at the time of UAT it was known to all that 100% test coverage was mentioned only for the acceptance criterias mentioned, not for the wjole test cases. And it really messed up both the teams in delivering the product on time. I am sure almost 99% of the team might have some assumptions as well, that are slowing them down.
So what I want you to do now as an exercise is to get out and walk around. Take a look at your team's area. Their task boards, maybe their definition of done if it's written out or printed up and see if you can spot at least three impediments
So we've already discussed about what are impediments and the places to look for impediments. Here is the 2F technique which you can use to discover some more impediments in your standup. 2F stands for Fourth and Fifth. Add the below 2 as the 4th and 5th questions of your standup. 

How confident are you that we will make our sprint commitment? 

This is a great question to ask during stand up and ask it to each individual person. If they answer anything less than 100 percent, that's an indication that there's an impediment there. Dig it deeper and figure out what it is so that the whole team is confident that they're going to meet this sprint commitment.

How can we go faster?

You might think that this will backfire and the team will just come up with a list of reasons of why they can't go faster. That list, that's your impediment list. If you're lucky your team will give you a bunch of things of what to change so that they can go faster. Again, impediments for you to solve.
So as an exercise I'd like you to think which of these questions is more appropriate for your team right now and ask them, either how confident are you or how can we go faster and note down a few more impediments for you to solve. 

Now you should have a really long list of impediments that you've started to spot but that doesn't do you any good until you start to solve them. Hopefully some of them will be quite easy to solve. But there's always some that are a little bit tricky.

And for that, wait for my next post where I will share some of my thoughts on how we can solve those tricky issues. If you have anything in mind, feel free to write it as comment so that others might find it useful. 

All the best with your agile impediments guys!

Tuesday, July 2, 2019

Who is a Devops Engineer ? A Guide to become a REAL Devops Engineer

- No comments

DevOps is one of the most widely and wrongly used buzz word in the IT Fraternity in the past few years and even now. Normally we hear a lot of things related to Devops. Companies adopt organization wide Devops policies, Started focusing more into automation and using more tools and  all this end up with another buzz role called DevOps Engineer. Organizations expectations about Devops Engineers are different and sometimes funny as well. Some people think, if you can do test automation you can be a Devops Engineer. Some might say like you are a good Devops Engineer, if you can do CI/CD or create a pipeline. Most of them see this role as a Super Powered Hero who  can do a lot of things alone, which was previously done by a lot of people. One role for too many things and that's it. 

So the question still remains un-answered for many with the same confusion. 

Who exactly is a Devops Engineer ? What is he responsible for ? What can we expect from them ?

In this post, I am trying to clear all your doubts regarding the roles and responsibilities of a DevOps Engineer.

What is DevOps?

The term itself is about eight years old, and big names such as Google, Amazon, Netflix, The Gap, and General Motors have made validating investments in it. If you ask this to 5 people, you are likely to get 5 different answers. 
  1. Is it a culture that we need to bring-in to our organisation to make ourselves more responsible and accountable ?
  2. Is it a Process which changes the way we work or enable us to deliver fast ?
  3. Is it a strategy to bring-in more tools and automate many things which will reduce human effort ? 
Actually my answer to this is as follows:

Yes It's a culture within an organization that increases the communication, collaboration and integration of the Development (which includes the QA team) and the Operations (IT Operations) teams.

Yes, It's a process which helps us to deliver quality product more frequently and reliably.

Yes, It's a startegy to automate and speed up the software delivery process so that those Human efforts can be re-invested to things that really matters. 

In-short, People + Process + Tools = DevOps 

It applies to everything from org structure to code structure to infra structure. 

Now comes the real questions which you need an answer for:

Who is a DevOps Engineer?

DevOps Engineer is an ordinary person who have some extra-ordinary skillsets as follows:
A person who understands and contribute to the software development lifecycle and has a  thorough knowledge of various tools for such as source code management, continuous integration, configuration management, Continous delivery, deployment and monitoring.

Who can be a Devops Engineer ?

With the above mentioned skillsets:

Mostly any System Admins who have a passion for coding and development realted activities or
Likely any developers who has interest in deployment and network related operations can become a Devops Engineer. 

I would rather prefer to say , DevOps Engineer is actually “Systems Engineer 2.0.”, somebody who understands the Software Development Lifecycle and brings software engineering tools and processes to solve classic operations challenges.

I have come across a lot of people in my life who claims to be Devops Engineers, without even knowing what does it require to be a Devops Engineer. These are the Must have skills to call yourselves a Devops Engineer:
  • Through Knowledge of atleast one cloud platform (AWS, Azure, GCP, Alibaba)
  • Good hands-on knowledge in dockerisation, monitoring, Configuration Management and Deployment tools like — Kubernetes, Puppet, Ansible, Chef, Terraform, Nagios etc. (atleast 1-2 in each category)
  • Proficient in any 1 of scripting language like Javascript, Go, Python, Scala, Ruby and C along with Git and Git workflows
  • Experience in developing Continuous Integration/ Continuous Delivery pipelines (CI/ CD)
If you think you have a tick for all the 4 points mentioned above, you can be proud to be a Devops Engineer, for the rest who are still in the same title but failed to get all these points validated against themselves, don't worry it's all about learning and improving yourself. At-least you know it now. So this is the time to start working towards it. I have an interesting picture from hiredevops which will help you with more guidance in becoming a REAL Devops Engineer.

I hope you might have found this article helpful in shaping your career as a better Devops Engineer.

Good luck!