Agile: My Experience
Agile: My Experience
Looking back on his time using Agile development methodologies, a developer discusses why he likes working in Agile and it helps dev teams.
Join the DZone community and get the full member experience.Join For Free
Agile brings a lot of benefits, provided it is used in the right way. I thought I'd share my experiences. Feel free to comment with your thoughts and experiences!
Agility (the ability to move quickly and easily) helps in making software development lightweight, easy, simple, minimizing the process and overheads, allowing you to meet and beat the market.
It majorly focuses on two parts:
- Ease the development process.
- Small & Incremental releases.
At a high-level, Agile looks very rosy, but, it all depends on the people using it. The Agile matrix is very important to execute the cycles, otherwise, the entire project could become tough to manage.
Agile is not about expediting things with rush or adding more pressure. Agile is for expediting the development and releases to meet and beat the market by augmenting the efficiency levels in the system.
Agile is not just splitting the whole work into some number of Sprints/iterations and starting development or trying to increase your number of meetings somehow. Agile is about bringing in more accuracy, predictability, and addressing needs early and quickly.
Agile is not about dragging out projects with rough estimates and constant change. Agile is about estimating with peers, allowing logical decisions to play a vital role.
Agile is not about burdening the engineer and trying to somehow get more features. Agile is about empowering the engineer to get his job done more efficiently.
Agile is not about just defining some process and follow. Agile is about individual interospection and retrospection as a team on what works and what not and drive towards the goal.
Agile is not about doing something and taking corrective or preventive actions. Agile is about avoiding stereotypical work and creating more bandwidth in order to create more business. For example avoiding manual testing.
It is important that we understand the major Agile frameworks in use. This article, I have covered more at Agile level (which can be customized to a framework) and not covered at the level of any Agile Framework.
Scrum vs Kanban vs Scrumban
Scrum teams work in iterations called Sprints, a duration with fixed start and end dates, to accomplish a set of tasks. These iterations help teams to give more accurate predictions, allowing them to effectively say when they will be able to deliver a piece of code. A time-bound commitment rather than an open-ended one, with daily update meetings (Daily Scrum), helps in creating early feedback cycles.
Kanban is like Scrum but the iterations may or may not be symmetric. The duration of the iteration will be defined by the team and there is no role(s) specifically designed for Kanban; though roles like Product Owner can be taken from Scrum - this is basically a matter of individual preference. Meetings are held on an as-needed basis.
Scrumban is combinations of Kanban and Scrum wherein, typically, roles are taken from Scrum and iteration models from Kanban. Meetings are basically held on an as-needed.
- Product Owner/Manager:
- A cross-functional team member who can envision the market needs, not just an analyst.
- Does market studies, gap analysis, minimizes customer pain, and works to make the product easy to use.
- Defines the features in terms Stories/Epics with exit criteria and stack ranks.
- Conducts functional workshops, explains the business needs, gives a detailed walkthrough of the final product, answers stakeholder questions/provides clarification.
- Asks for frequent, intermittent releases that can be tested hands-on and signs-off on the releases from the functional point-of-view.
- Overall, accountable for Product Success/Failure.
- A team, typically, is made up of 8-9 developers, who are expected to be self-organizing.
- Does detailed feature study/analysis, and estimates and defines the low-level tasks and development features.
- Picks up an estimation model that works for them - could be choosing even/odd numbers, t-shirt sizes, Fibonacci sequence, card game style, etc.
- Split the work into granular levels, come forward, pick the items, and get it done.
- Designs, develops, tests, and supports the product.
- Updates daily progress in stand-ups on what is done, in-progress, and what's next.
- Individuals are responsible for accomplishing the tasks as per the estimations agreed upon by the PO, Team, and EM.
- Engineering Manager:
- Typically, a techie who understands technology a lot or could be hands-on, and management/functional to some extent.
- Helps the team in all technical, functional, and managerial aspects. Works along with the team owning end-to-end deliverables.
- Coaches the team on the execution model. Works closely with Product Owner and Team to help them agree on the deliverables.
- Ensures team necessities, requirements, eliminates unnecessary overheads, processes on teams.
- EM is not a Project Manager. Do not mix with other methodology roles/responsibilities as this could change the whole game.
- Gather info, identify and eliminate impediments, shields team from external/internal influences.
- Makes decisions at floor level, helps the team on technical/functional/managerial aspects.
- Experience in architectural, design patterns, open source platforms, frameworks, technologies, and standards.
- Accountable for design, development, quality, timely releases, consultancy, support, and generally making the product better from an engineering point-of-view.
As a team, identify a model that works. Basically, choose a series such as Odd/Even, Fibonacci, or T-shirt sizing.
- Individuals come up with estimations for the stories/epics. Logic should win (not authority/voice/influence/reference powers).
- Estimation works well when the actual contributor estimates the work and it can always be cross-checked within the team.
- Do not try to mix-and-match estimations and try to compare them. Do not try to compare component based vs functional point vs story point estimations, it will not work and will not help.
- Any changes in the estimation model will not give accurate data for predictions.
- Any major changes in the team could bring a change in the estimations and release predictions.
- Do not try to compare estimations across teams. Most of the times, it won’t work.
I have kept very high level on the below topics but otherwise each and every area can be an article byitself.
- There is a lot of engineering work to be done? Such as:
- Technology stack selection.
- Proof of concepts.
- Framework and utility development.
- Design and Integrations
Once this platform is in place, on top of it, value/functional stories can be developed. So, have Sprints for all the engineering work to be done (Sprints are not just only for functional requirements).
- Are there a lot of testing cycles involved?
- Agile will not succeed without proper automation, continuous integration and testing, and a lack of these could end up in huge spillovers, and the project would become unmanageable.
- Automate as much as possible as this would help the team to focus more on value stories than routine testing work for every other change.
- Are there a lot of meetings involved?
- Avoid too many meetings. Try to connect directly or have more workshops to work closely and help to close things early.
- Bigger team?
- Have multiple Scrum teams, each with about 8-9 people, and do a Scrum of Scrums. The overall update will be at the Scrum of Scrums.
- Too many communication points and channels?
- Do not try to somehow match the numbers in the tool to maintain velocity and burndown for the sake of doing it or for the reports.
- Involve the team to update the data in the tool as they progress.
- Data keyed into the tool by the contributor should reflect the overall status.
- In the support and enhancements phase:
- Come up with capacity planning and bucket them into areas you might need to work on.
- Plan Sprints for the enhancements and on any important customer issues, bargain/swap the internal development tasks with the issues.
- The whole game starts with the RFP to win the customer.
- It helps if the organization has already executed projects like this, as it will allow for better estimations. The challenge remains for the first-timers. So, if the project is given the green light, a blueprint would help here.
- There's a good chance that people will estimate only for value stories and could miss the underlying design, framework, and integration engineering work involved. So, consider the engineering and functional work involved.
Agile is not a better word to use if any or none of the below are in place:
- Right tools
Quantifiable Code/Test Metrics
Many tools available help in executing Agile practices, but it all depends and matters on how easy they are to use and if we are really using them.
Finally, Agile allows us to have less process overhead and work more on the engineering.
Refer to my article that could help in building a part of an Agile development environment.
Opinions expressed by DZone contributors are their own.