What can agile do for you?

After years of experience working with, training on Scrum/KANBAN, I have no doubt that Agile estimation techniques are better than classic, predictive estimation techniques. Still, daily basis involvement with Agile will leave many questions that kept nagging me over time. With such thoughts in mind, I feel it is important to socialize, meet and discuss with likely minded people. Recently I have had an opportunity to join ‘Agile Women – UK London’ meet up. The meeting was nicely organized, the whole session was filled with brainstorming activities and I adored each moment spent. I am writing this blog to share my learnings from Lean coffee meet-up right from the way it is organized to some of our discussions which most of us face in our daily working life.

Meeting discussion was based on the Lean Coffee format in a very casual relaxed environment at the Groucho Club, London. As per Lean coffee format, we all had a clear agenda to discuss – Any question or thought that arise when we are working in the agile process. Womenfolk’s assembled were covering every stream, to recall few were Project head, Business Analyst, Scrum master, Test Manager, developer, Team lead –from MOJ, Home Office, HMRC, HSBC Bank, DWP, and Telefonica O2 and many other companies (it really helps to see diversified views). A random group of 4 to 5 were made, after a quick introduction (even it included our main objective of joining this meeting) we were given post-it notes and a pen. Everyone started to note down literally whatever one wants to discuss or to follow a theme. Every member gets two votes to decide which topic they also feel interesting or is a good topic to discuss by putting a dot on that sticky note.  At the end, we sorted it with the highest count as our first topic to discuss within a group and so on. To kick off the discussion a person who had written that note will explain their objective and what they are expecting out of the discussion and then everyone will start adding their thoughts to it. At the end of the discussion, we conclude and move onto next topic to discuss.

 

 

 

Picking up few of the topics, I would like to highlight some key points.

We don’t TRUST agile

To start- with all the build-up in the industry about Agile, Scrum – it is no surprise that many companies hear or read about the benefits of these methods and think “we need this here”. And when Scrum is introduced in a company, most of the time, the team embraces it with lots of enthusiasm. But unfortunately, after a happy honeymoon period, some might think they are not as ready to make the mental shift required to embrace the agile way of doing things. Especially to accommodate the changes that keep happening in most of the sprints, sometime this eventually lead to loss of trust in Agile. What one needs to understand is – in agile, we welcome change, we want the backlogs to change. Road maps are not set in stone, program road maps are meant to change. The team should be capable of releasing every (short) iteration – that’s what makes the program effective and allows the program to change which in turn ensures the company to release a valuable product faster. By doing it an Agile way we are enabling the end user to see some results at the end of every sprint which might not happen in other conventional methods. It makes me recall what Steve Job once said: “the users don’t necessarily know what they want until after they see it”.

To get fruitful results of Agile, what we need the most are – The Teams who commit to delivering features often, might not be every time but most of the time- such teams are reliable. They don’t have to have predictable velocity, but they have to have predictable throughput. That means they might not realize how large features are, but they continually finish features and release them. The Management who commits to managing the project portfolio so that work flows through the teams. The teams work on only one project at a time. This allows the team to swarm over a feature and push it through. And the Product owners who understand how to create a product roadmap and know how to create a product backlog for a team/teams to consume.

How to implement the feedback from Retrospective effectively?

The retrospective can be an opportunity for the whole team to look back and reflect on what they’ve done and how they’ve reached a certain point together. It is as important as planning. A meeting involving the whole team at the end of a cycle in an agile project or Sprint to identify any improvements which can be made available in an upcoming sprint. It is also an opportunity for everyone to come and express their view. Simple way of carrying Retrospective is to get feedback for below questions from every member of team

  • What went well?
  • What wrong?
  • What did we miss in this sprint?
  • What do I want to improve on, to make next sprint better?

To conclude – Positive points from above discussion are always good. They really do motivate for coming sprint but what we might miss is to implement the rectification of what went wrong in the previous sprint or what can be made better in next sprint. In such cases, there are two suggested options

  1. If only few action items are there, then it is important that we assign it a person who will make sure this actions is met in coming sprint or at least to make it better than previous sprint
  2. If there are multiple actions and already seized with current sprint planning then prioritize the actions and try at least the top one is addressed.

In the end, we have to understand that analysing problem is not a solution. Implementing a course of actions in a way to make it better is the solution




Continuous Integration

This is my sense of how different it is from working in Continuous Integration (CI) environment to working in the traditional way. The traditional way of developing software was brought smiles till the development environments start becoming complicated.

                                                                             

Things start breaking when a number of developers are involved and the traditional way of releasing product becomes complicated when several developers started releasing their code to the single server at the same time.

                                                 

There are many reasons why continuous integration is necessary, but none are so important, so essential, as “meeting the expectation”. Often we see that one of the fundamental failings in software development is the breakdown in meeting the expectations set by the business from Developers. Everything starts out fine, with management asking the developers for the amount of time it will take to implement a feature. The developers provide an answer, and management takes them at their word.

Consider this. On an average developer may view development as composed of the following steps:

  1. Determine what needs to be created or fixed
  2. Implement the feature or fix
  3. Manually check that their feature works or fixes the bug
  4. The job is complete. Move on.

The individual developer works on creating/fixing different features of a product and once their job is complete they take up the next task. By the time they reach a deadline, most of the time one of the below situations results:

  • The product is still in-progress/incomplete and is on the virtue of deadline
  • Or the Product is delivered, but it’s either faulty, creates new bugs, or both.

Any of the above two situations are neither good for management nor for a developer. With no doubt, we have lots of new tools, theories or practices, but in the end, we could never predict whether the product is going to be a bug-free. All we could say is to learn from experience and try to make it better next time. The topmost fundamental reason for not meeting the expectation by Dev team is –Impact analysis of the new changes, which might have impacted something on which another code is dependent on, or tests pass on their machine, but fail on someone else’s or as the system continues to change, will their manual test still be applicable? If so how long would it take? Would testing team repeat the test the same way every time?

There are so many unknowns, so many questions, and so many factors you can’t control. The possibility of being tripped up by any one from Team is extraordinarily high. By practicing continuous integration at the core of your approach, the unknown becomes known, little by little. It holds the promise of providing proper application validation.

So what is CI?

Martin Fowler says – “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible”.

And the main essential tasks of CI can be highlighted as –

  • Maintain a single-source repository
  • Make your build self-testing
  • Automate the build
  • Everyone commits to the mainline every day
  • Fix broken builds immediately
  • Keep the build fast
  • Make it transparent
  • Test in a clone of the production environment
  • Make it easy for anyone to get the latest executable
  • Automate deployment

Read more on the topic here: https://mikeciblogs.wordpress.com/tag/continuous-integration/ by Mike news

Some top benefits of using CI and why one should consider it from the beginning of your project.

  • Deploy your code to production: the CI server automatically deploys your code to production if all the test within a given branch is green. This is what is formally known as Continuous Deployment
  • Build Product now: Once all your tests are green and the coverage is good, CI servers can also trigger build and compilation processes that will take care of your needs in no time. The CI server will run within its scripts and notify you as soon as something goes wrong.
  • Build product/feature faster: With parallel build support, you can split your tests and build processes into different machines, so everything will finish even faster than if you ran it locally. It will also consume less local power and resources, so you can continue working on something else while the builds run.
  • Detect system development problems earlier: Having your code tested before and after it is merged will allow identifying system problems earlier by decreasing the number of times
  • Reduce risks of cost, schedule, and budget: CI and Version Control Server communicate with each other and tell you when a merge request is good to merge. It can also show how the code coverage would be affected by it. This can dramatically reduce the time it takes to review a merge request. Continuous automatic regression test unit will aid in minimizing the cost, resource and time

Continuous integration helps keep us to keep our process honest and transparent. It validates against our assumptions and changes. And it is a process we can use in every moment of our work day to ensure that the software we are building is improving and not decaying.