In today’s post, we will explore the remarkable success of Agile methodology in the realm of Information Technology and Business. Since its introduction, Agile has revolutionized the way projects are executed, delivering tremendous benefits to all parties involved. From stakeholders to developers, the advantages of Agile methodology have made it a go-to approach in the industry. Join us as we dive deeper into the world of Agile and uncover the transformative impact it has had on IT and business landscapes. Discover how this methodology has empowered collaboration, efficiency, and overall project success for all stakeholders involved. Let’s explore the exciting world of Agile together!
Before you start
About this post:
- 10 – 20 min average reading time
- Suitable for beginner’s through to advanced
What you will gain reading this post:
- The benefits of Agile
- An understanding of what goes wrong
- Idea’s for improving your Agile experience
- Recommended tools for running Agile
What you can do to help support:
- Like, comment and share this article
- Follow this blog to receive notifications of new postings
Now, let’s get started.
What are the benefits of Agile?
There are many great benefits when running your projects using Agile.
The team members are all involved from the beginning
In previous popular methodologies such as waterfall, incremental etc
- Teams members were separately operating from one another
- There would be the business analysts producing a massive requirement document which would be continuously changing
- The developers would be developing a solution based from the requirements as well as producing several design/development documents.
This would often result in
- A stale product at the end of the cycle and being different from what the business expects
- The testers would be waiting for the development cycle to complete before their role would commence
- The business would be excluded from the process completely
Due to the nature of agile
- All the team members are interacting from the beginning
- Once the backlogs are assigned and the sprint planning commences it involves the business, business analysts, developers and testers all discussing what will be included into a sprint
- Once a sprint is decided the individual details of the cards are discussed and detailed by the business analysts, developers and testers through short meetings and the information is recorded against the card with all members understand what is required as well as the effort involved.
Sprints are short and time boxed
Once again in the older methodologies
- Money, time and resources could be greatly wasted as projects could have months or years before a product is produced
- This can result in a product that is not satisfactory to the stakeholders as well as a cancelled project for various reasons with no product to show
- Typically sprints vary from 2 weeks to 4 weeks depending on the size of the team and what the organisation would prefer to follow
- A set of points are assigned to this sprint and those points are completed during that assigned time frame
- At the end a product is produced, which is shown to the business where they can see that it is as expected and if the project is cancelled you will have a product with a subset of functions from the overall project
- This in turn will allow the stakeholders to to have a completed project at the end of the project life cycle or simply have a deployable and usable product if the project is cut short.
Progress is communicated regularly
- The team including the business
- If they wish to participate gather each day at the beginning of the day to quickly run over the board of cards they are working on
- This allows the team to know the progress of everyone as well as any blockers that can be addressed and what will be planned for the day
- If a team member then is sick it is more simple to take over the task of that individual and allow for issues to be highlighted and resolved quicker.
Cards can be shared and assigned to different team members
Typically in the older methodologies
- A piece of functionality is assigned to an individual and it is their responsibility to complete the task
- If the person resigns, goes on holiday or has a sick day it is hard to pick up where the person left off as the task generally is not broken down into small requirements
- The functionally is broken up into logical groups allowing any individual to pick up a task for a sick member as the card will generally not be a big group of work
- While that card or once that card is being worked on or completed depending on the dependencies
- Another team member can take on the next card which also distributes the knowledge across the team and reduces project issues if an individual resigns.
Clear and structured workflow
- Having a visible board in front of the entire team allows the team to always see who is working on what and where that card is in the workflow
- This allows for testers to prepare the environment for after handover is completed
- The sprint manager to see what has been completed and update the burn chart
- Developers to see what is next to be worked on based of priority.
- It is a completely transparent environment making it clear for all.
An example workflow for a sprint may be as follows:
Ready –> In Progress –> Completed –> Ready for Test –> In Test –> Completed and also a Blocked column
- Handovers are generally performed by the business analyst when changing from Ready to In progress to the developer and tester
- Developer generally performs the handover to the tester and business analyst when changing from Completed to Ready for Test.
Avatars are created and each card will have a developer/s and tester/s avatar assigned, they clearly indicate who is working on the particular card.
Allows for research
Agile allows for what is known as Spikes
- These are like other cards where points are assigned and they are time boxed
- This allows the assigned person to perform research and gather the required information while at the end make an informative decision based off your findings
Allows for code re-factoring
Given the nature of agile
- The cards assigned typically do not exceed a particular points value meaning that the assigned card is not to large.
- This in turn allows for small areas of the code that are being touched to be improved and re factored.
Product is well tested
Typically following agile
- Most organisations are embracing the TDD approach to testing, in short this is where the tests are written before the code and then the code is developed slowly fixing the errors in the tests.
- This allows for a firm understanding of the requirement as well as a structure design as you want to ensure all areas you are writing can be tested resulting in the the team more confidence and a more stable product.
- The product will contain unit testing and may contain BDD testing to test various business cases, as well as UI testing across various browsers to ensure that the UI will work across multiple browsers that are required.
- A Continuous Integration build is normally configured where end to end testing is performed and depending on the project and requirements it will also perform performance testing
- At the end of each sprint will be a successful build where all the tests have executed and successfully completed ensuring a well tested product.
Product is deployable at the end of each sprint
After each sprint
- A working deployable product is produced and can be used
- It will not be the complete product until the project is completed but it will be a working subset of functions that have been developed and as the sprints increase so will the functionality of the product
Business is aware of progress after each sprint
For the older methodologies typically
- At the end of a particular milestone when you could demonstrate a working product, you could show this to the business and most of the time it would result in an overall approval but also require many changes and much rework
- They would see changes that would improve the product and since much work would have been done on the product much rework would be required
- At the end of a particular sprint a showcase is arranged and this shows the stake holders and the business the work that was assigned and completed as well as a working product in a deployed environment.
- This is a fantastic way for the business to see the product and confirm that their expectations have been met and for the stake holders to raise any questions or concerns about the progress.
- It is also a great way for the team to hear feedback and see and hear the approval of the business.
Reviews and improvements are performed after each sprint
Typically following the older methodologies
- There is not really an improvement / review process of how the team is travelling and what issues are being faced, these can occur on milestones but is not often done.
- This is known as a retrospective where the team excluding the business get together and discuss what worked, what didn’t and concerns / questions they may have
- From this typically a subset of the most popular based of voting is discussed and some action points a created and assigned to the relevant individual to action before the next retrospective.
- This allows for continuous improvement and to reduce reoccurring issues as well as for the team to see the successes and hopefully enjoy a drink and some food together
What typically goes wrong!
- Scope creep
- Cards are marked as ready when they are not
- Team members
- Are not across various functionality
- Deviating from assigned card
- Not attending meetings such as stand-ups and sprint planning
- Builds are left broken
- No adequate testing is performed with each card
- Retrospectives not taken seriously
- Lack of feedback from business at showcases, this includes praises
- Handovers not performed in correct environments or SOE
Ideas for improvement
Get the business involved with Agile
Typically in organisations is it very common for the business to not work as an agile team.
- This in turn makes it more difficult for the business analyst who spends most of their time in meeting determining if the business really do want a particular feature to be added and what details are included and missing.
Much time and cost can be saved if the business have their own agile board.
This would involve them driving that particular board with the final handover occurring between the business and the business analyst.
- This ensures that the business manages their own backlog and understands what the complete picture entails as well as all the relevant details that are required and detailed before approaching the business analyst.
- It will also allow them to time box the sprint ensuring there is no waiting of lack of cards from the business and allow them to understand the points involved for them to complete the relevant card with relevant details.
I have seen this in practice and believe it to be a key component especially in large projects.
While the purest approach is not followed, at least in most organisations
- It is important to be firm on the key factors that help make agile the success that it is
- Many times in projects scope creep is a huge concern, typically the business will discuss a topic and decide that some additional details are missing
- It is important to have a team that can push back on the additional requirements and lock down the sprint in progress once the card are decided and in play they should not have the requirements changed
- Ensure the scope creep is recorded on a new card and added into the backlog to be discussed during the next sprint planning, this will make the team less stressed and allow for less bugs to creep in
Ensure handovers are correctly done
- With the relevant team members
- That they are demonstrated in the appropriate environment
- Ensure testing is completed before the handover between the developer and tester
- This can get missed or skipped when the sprint is coming to an end
- It leaves a less tested and reliable product at the end of the sprint and it would be better to move cards that are not completed to the next sprint rather than to not completed cards correctly
Review your estimation through the sprints
- Typically the estimates are quite off at the beginning of the project but as the team becomes more familiar and better accustomed with one another the estimates will become more accurate
- Reviewing will help with the sprint planning and estimating.
- Ensure that the relevant charts are maintained, charts such as burn charts are fantastic as they allow the team to see the daily progress and improved on estimate for the next sprints
- Make sure that the tools you use and the board are aligned.
- For your fellow team members
- Be punctual to meetings
Keep stand-ups short
- If further information is required schedule a meeting after stand-up
Ensure that testing is completed
This is one of the most important steps to ensure a successful product at the end of each sprint
- Include as much tests into the project as possible such as
- Unit testing
- BDD testing
- Integration testing
- End to end testing
- Performance testing
- Following a process such as TDD will greatly increase the reliability of the product
- Ensure that you have a dedicated build tool to run your tests locally and on the build server
Ensure team members work on different cards and functionality.
- This will make a difference once team members are away sick and another team member needs to continue with the card
- If teams members are not always assigned to the particular functionality then you will have a team that understand the entire process and allow for better sprint planning
Ensure the team reflects
- Sprints can be very stressful for all involved especially if the project encounters a few hiccups along the way.
- At the end of the spring during the retrospective make it enjoyable, this will encourage the team to express the true issues and successes and contribute more to the actions and participation, this could involve providing drinks and food at those meetings.
Recommended tools for an Agile project
- Is used for keeping all the cards and details related to the cards as well as backlog and sprint information
- It integrates with other tools such as source control so when code is committed the card will be updated with the commitment comments
- It’s great for progress reporting, points assignment, workflow between statuses and team members to reflect the physical board and team management
- Great, for smaller projects such as home projects
- It is a great way to create a virtual board and manage your progress with small teams, the only downfall is it does not record points.
- For small projects and teams that do not want the ongoing cost of maintaining a physical board then this is a great alternative
- Is a great build tool and easy to configure, it contains many plugins and a fantastic tool for executing tests.
Did this help?
- Like, comment and share this article
- Follow this blog to receive notifications of new postings
- View previous postings