Most of the teams in the software world follow Agile process and practices. Following Agile is fundamentally different from being Agile and in this article, we will talk about some of the actions you can take today to be more agile.
do you follow?
Shed Ego: Ego is a big blocker for our progress irrespective of being in the Agile world or not. But this becomes even more evident and blocks our every step in an Agile environment. There are lots of articles about egoless development.
Be open to collaborate : When we are open and talk our mind, we automatically become more agile. The restrictions and mental blocks to speak our mind openly to the team are the biggest bottlenecks to free flow of information and ideas. Psychologists call it emotional security to speak our mind.
Don’t Use communication tools: In this age of technology, the tools are plenty for communication, but none of them provide the connect of the face to face communication. (Agile principle)
Focus on the outcome: Lot many times, the agile manifesto is being misinterpreted (“working code is a measure of progress”). Unfortunately, it does not talk about production. Some teams get very complacent when they get their working code in “QA” or “Stage” environments for example. There is no result when the working code is not in production. At the end of the day outcome matters.
Get things done: Just like any other methodologies, the trap always exists when teams get lost in the process and meetings. The important part of the business and the product is to deliver things. So never move eyes away from the delivery.
These are the few actionable you can take today to be more agile and be awesome developers and technologists. So take action now!
The Agile is not just following Scrum or XP. There are many other agile frameworks or methodologies available in the Agile world which are leveraged based on type of work or a project. There is none better than other. The use completely depends on the type of the project you have. There are many methodologies available in the market while I will be listing down high-level details about some of the core methodologies below.
The team works in iterations (Called sprints) that are typically 2 or 4 weeks.
The engineering practices are not prescribed.
The scrum does not encourage change within sprint once a commitment is made.
The backlog is prioritized while within sprints team decides how to go about picking items. The priority is typically given by product owner.
The releases happened after the end of iterations.
The scrum can be used for non-software products.
Encourages feedback early while it’s fine to reach to the point till you have sprint review.
Extreme Programming (XP)
The team works in iterations that are typically 1 or 2 weeks.
The engineering practices (TDD, BDD, pair programming, automated testing, refactoring etc.) are prescribed.
The XP teams are open for changes as long as the feature hasn’t started or they have similar size of an item which can be swapped.
The work is done in strictly priority order. The priority is determined by the customer.
The focus is more on small and frequent releases.
XP focuses on programming.
Immediate Feedback loops.
Lean and Kanban
The lean concept has come from lean manufacturing where the focus was a continuous flow of work and eliminating waste (Muda).
Kanban (Billboard or signal board or visual board in Japanese) is one of the lean methodology sometimes referred as Lean Kanban.
The core focus is on visualization, work in progress limits, flow, and continuous delivery. The work is in one of the categories (to-do, doing or done). There could be N-number of categories.
When we talk about software, it is most suitable for support kind of work.
No required time-boxes or iterations.
No set process roles are prescribed unlike Scrum where you have three roles defined (Scrum master, product owner, and team member)
Feature Driven Development (FDD)
An iterative and incremental software development process which is often referred as a lightweight Agile process.
The focus is on features.
The main purpose of FDD is to deliver tangible, working software repeatedly in a timely fashion.
The unit testing, pair programming, refactoring is not important. Modeling language (like UML) is leveraged and documentation is not mandatory at all.
Agile Unified Process (AUP)
Simplified version of RUP (Rational Unified Process)
The four phases are inception, elaboration, construction and transition.
Inception – Stack holder acceptance, Initial requirements, high-level architecture, and scope is baselined here.
Elaboration – The detailed design and architecture are accomplished in this phase.
Construction – Working software building incrementally.
Transition – Release and deployment
The focus is on TDD, Refactoring, change management etc.
Dynamic Systems Development Method (DSDM)
Focus on developing the system dynamically based originally on Rapid Application Development.
It has primarily 5 phases
Functional/Business Model Iteration
Design and Build Iteration
Above is very high-level information to get a hang of it. I shall be writing individual blogs about these methodologies in detail in my upcoming blogs.
As an Agile team member how can I be an expert at project is one among a common question I hear every time. The world is changing so fast, the evolution of tools and technologies making life so easy when it comes to implementation or writing code. When you talk about career, everyone wants to grow vertically and the easiest option I see to achieve this in product based companies is to get better at product and domain in addition to fulfilling your agile roles and responsibilities. This would help you to stand out in the crowd. To be honest, this is an easy path which lot of others do not want to take.
I am listing here top 10 ideas to be considered to grow vertically in product based organization.
Spend 30 minutes to an hour every day to learn about the product by playing with product, testing out functionalities, reviewing code other than your normal work.
Review existing documents around product. Whenever you see an opportunity correct them. Document your learning and contribute your knowledge in organization PAL (Process Asset Library). Writing or teaching anything to people helps you to move the knowledge to your permanent memory.
Whenever you work on any sprint item (like bug, story, tech debt or spike), ensure you understand the user value proposition of that. Always ask yourself why I am doing what I am doing. How does it helps business?
Understand all the integration with your product.
Search on internet to find competitors. Find out what features we are lacking what our competitors have. What is that we have and others don’t have? Propose PO your learning and ideas.
Participate in calls related to vision, roadmap or release planning.
Communicate more with business owners. Understand priorities, business need and what is coming next.
Ask question when in doubt. No question is a stupid question.
Participate in showcases/demos and cross functional calls. Ask questions. Share your knowledge to others in team.
Once in a week have a session with whole team to talk about product, domain, innovations and learning. Encourage everyone to share their thoughts.
I am sure doing some of above would boost your career in product based organization.
I am listing most important factors which an agile leader must focus on, in order to be successful in his/her role
People, people and people
Building Relationships with all the stakeholders
Business Alignment (Clarity of vision and mission)
Sprint Success and Continuous Improvements
Relationship within team
Promote “Fail Faster, succeed sooner”
Frequent feedback loops
Lots of fun
Visibility on current status
Let me tell you honestly, there is nothing more important than people. As a leader, you should focus on people, their careers, growth, motivation and anything what you can support them to add value to their personal lives. Don’t forget to appreciate good work and at the same time it is important to provide feedback around areas of improvement. When you think of growth, think about your team’s growth. When they grow, you grow.
Provide them opportunity to become better individuals. Inspire them to learn and get better. Feel pride in their success.
Strong relationship with team and stakeholders make life easy. It’s not just about bringing in empowerment while at the same time it is important to understanding everyone’s need and expectations. The great relationship with business, management and team helps you to have
Access to more information
Business Alignment and Vision
If you don’t know where you want to go, you will reach nowhere. As an agile leader, you must ensure that there is a clarity of vision and mission for you and your team. Moreover everyone is aligned to business needs and expectations. You should often ask yourself and your team about USP (unique selling proposition) of what you are building.
Self-Organizing Teams and autonomy
Don’t hold your team too tight that they can’t breathe at the same time don’t leave them to do everything by their own assuming they would become so called “self-organizing teams” by themselves. The ultimate goal should be to build self-organizing team and if you are successful in doing so, the chances of you being successful is very high along with your team.
Always focus on sprint success. When you start, do it less and then improve. Never get into discussion with business or management that we are delivering enough for our need hence meeting commitment is not important. Do whatever it takes to make sure your sprint is successful.
Everyone contributes and Continuous Improvements
If this doesn’t happen then slowly you would see your self-organizing team start deteriorating. Everyone has different skill and competence hence you can have different expectations while everyone has to contribute. One rotten apple spoils entire basket and this no different here.
Relationship within team
If you have happy team that gel well with each other, you are likely to do much more. If you’ve highly competent individuals in team but team members don’t go well with each other over a team which has lessor experience and competence with strong bonding then your chances of getting better output in team with good bonding. Do whatever it takes to make your team align and build a bonding among them. By doing so, you are significantly improving the chances of your success.
Collaboration and Communication
Agile team cannot run in Silo. The collaboration nothing but working with cross functional teams to accomplish a task. This encourages communication among business owners. The communication within team is also very important. The output will be produced by team and not individuals. It helps in removing impediments faster as well.
Promote “Fail Faster, succeed sooner”
It’s not a perfect world. In order to be successful with Agile there should be an environment where everyone encourages individuals to experiment. It’s OK to fail and that’s what lead us to be successful. Fail faster, succeed sooner is something you should not just feel while you are expected to enforce that in your team.
Release as much as you can. I have seen teams releasing every day or even post every feature completion. This is a challenge at a times or product which are quite big and needs significant testing. More you do, simple it becomes. The moment you start thinking about releasing frequently, you would focus on automation tests. That something most times become last priority which is not at all good.
Don’t wait for showcase to provide feedback. The code review phase is not important to provide the challenges or best practice. Talk more. Provide feedback then and there. Look for ways to get the feedback from customer, PO or other stakeholders as soon as possible.
Lots of fun
Start with fun and then get on to work. Don’t wait for you to be successful to have reward. There is going to be celebration for that as well while create an environment where everyone feels comfortable and enjoy working.
Arrange a training. Talk about process. Doing agile is probably easiest thing while doing it RIGHT is what really needed right mindset. There are many teams I have seen they do “waterfall agile”. They are basically trying to do waterfall within each sprint. Not good!
Visibility on current status
Create various matrix to ensure things are on track. Utilize standard artifacts like burndown charts, velocity report etc to see where you stand. You can fix the issue and come up with finding a right solution only when you know how are you doing.
Themes – A Theme is a group of EPICS that represents area of focus. For instance “Product going online” or “moving to cloud” or “launch in India”. Typically program managers assign financial value to themes to ensure objectives and strategic direction of an organization is aligned with program. These are typically at very broader level (Program or entire project level)
EPICs – An Epic is a large story that cannot be completed in a single sprint hence it is broken down in group of user stories. Hence it would make more sense to say that EPICs are collection of related user stories. For instance you say that theme is “Going to cloud” and EPIC is “improve password page usability”. The user story could be “The validation messages should be very clear so that I should be able to correct it easily”
User Stories – User stories is a description of a software feature from an end user perspective who desires the new capability. Precisely it is simplified version of user or customer requirements.
Here is the template for user story
As a <type of user>, I want <some goal> so that <some reason>.
A good user story can convey a clear understanding to programmer about requirement. The characteristic of user stories are
Testable, Estimable, Small, Negotiable, Independent and Valuable.
A specific user story can belong to more than one theme, but certainly does not to multiple epics.
Let’s talk about Demo/Review or Showcase in this article
A showcase, demo or sprint review represents one and same thing. A sprint review is an informal meeting that typically takes the form of a demo of the completed features or what is accomplished during the sprint to the product owner (And rest of the team).
This can be done as and when the work is completed over waiting for last day of the sprint to arrive. This mitigates the risk of incorporating review comments which may result in sprint failure if the demo is done on the last day of the sprint. In case if there are review comments, that should be fixed and once again demo to be conducted for the story which had review comments.
The whole team should participate. Although the team needs to get the buy-in from PO to change the story to done-done while the feedback from the whole team helps. You can invite other teams, support or customer as needed.
One of the core objectives of the demo is to review progress against the sprint goal and team commitment. It is an opportunity to get everyone on the same page in terms of what was accomplished, what’s still in progress and what tradeoffs were made.
Best practices around Demo/Showcase
Prepare, prepare and prepare – Don’t go to demo meeting and start talking randomly. Everyone’s time is important including you.
Practice before the demo – Run the workflow or the feature you have built. This ensures everything works.
Give importance to Acceptance Criteria – You can always talk about nonfunctional requirements while the focus should be on acceptance criteria. What value your feature is adding to product/business.
Follow KISS – Keep it short and simple – Don’t complicate things. Make it crisp, cover all the points written down in acceptance criteria. Give time to your team and PO to ask questions.
Showcase Value – Do not focus on technology or the feature you have built works while do talk about business value. Feel the sense of pride or accomplishment in showcasing what you accomplished.
Communication – It’s key to success. Talk to the point. Listen to people (your team). Write down their feedback and comments. The good idea is to record the meeting so that you can always go back and listen to the feedback if any.
Involve right participants/stakeholders – Not just your sprint team or PO but you should be inviting folks representing your product business. Folks on the actual ground adds lots of value to the project/product.
Seek Feedback – Accept the feedback positively. Your goal is your team success, making a product better and help the organization to get more value. This eventually helps you to grow faster.
Let’s talk about planning and grooming in this article
The entire sprint team work together and plan for next sprint goals. The sprint planning meeting is attended by the scrum master, product owner and rest of the Scrum team. The other teams may be invited on a need basis.
The PO ensures product backlog priority is up to date (At least top level items) for the team to pick up items from the product backlog. The stories are picked up and prioritized. The PO usually talks about sprint goal and once that is finalized, the stories are being picked up to for grooming.
For each story, product owner writes down the description of story and acceptance criteria. While grooming it can be further updated by PO and team. The team gets answers for their queries from PO with respect to functional expectations. In addition to that team work together to identify dependencies, constraints and nonfunctional requirements. The team typically elaborate more on functional requirements as well. The stories are broken down into multiple tasks.
All the groomed stories are then estimated by the team. Each story is tagged with story point or hours. The task usually is tagged with planned hours. The scrum master and team look at the velocity and capacity of the team and commit the amount of work which can be delivered in sprint.
At the end of this meeting, the scrum team would have two artifacts ready
I always suggest the team go with pre-grooming. Typically planning happens a day before or when we are about to start a sprint. Understanding every story the first time, grooming, tasking and estimating take too much of time. Due to time constraints, it is not very effective and done half-heartedly. Moreover, all the questions can’t be answered upfront. This is one of the main cause of sprint failures in most projects as you are not sure of what you are committing. One of a good idea is to keep looking at upcoming stories and clarify all the doubts with PO or other stakeholders in advance. Spending 30 minutes to an hour by few folks in team 4-5 days in the previous sprint helps to do much better for next sprint. With this, the planning meeting will have just three goals
Explain everyone expectations from stories and get aligned
Once #1 and #2 are done for all the stories, commit sprint.
Note: Many times, the business and competition demand last minute priority work to be picked when you start the Sprint. This is fine as long as it’s minimal.
PO shouldn’t be telling how much of work team should be picking. The team should take a wise decision by looking at previous sprint capacity. The idea is to have sprint success and continuous improvement.
Always keep little buffer for planning next sprint items, unknowns in existing sprints and tech debts
A lot of teams prefer to keep 20% time aside to deal with tech debts. This may be a good idea while I always suggest the team to plan for this 20% during sprint planning and grooming only. What you plan is what can be accomplished.
Don’t be very aggressive as the quality of software in most cases is more important over quantity.
The team member shouldn’t be picking up multiple stories in advance. Each and every member should pick one story and once done they should move to the next one as per the priority order specified in Sprint. The exception to picking up the items within Sprint should be ok as long as PO is good with that.
Always create a task for stories. Don’t just include tasks which have business values while do consider tasks related to development and testing. For instance testing, code reviews, writing tests etc. Keep in mind, don’t write too many tasks.
Try to break down the story to as small as possible while if the estimation is going beyond then it’s important to divide that into smaller stories. There are instances where you can’t break down the story to the level where you are not getting business value out of it which is OK at a times but do avoid this situation as much as possible.
The story where lots of research is involved and there are unknowns which need to be unearthed, prefer to go with Spike.
Trust each other and support each other.
Pair when needed while do not work on the same task in series unless absolutely necessary. I have seen with the offshore-onshore model, the story is being worked on one story at offshore and further, it is handed off to another team member at onshore. These cycles keep repeating. The amount of productivity loss happens in this approach is not worth it.
Important Tip – The scope creep can be managed within Sprint with only two ways
Refuse new work in the middle of Sprint and take up that in next Sprint.
If it’s absolutely mandatory to pick the work in the middle, you need to take out an equal amount of work from Sprint.
At times, you are done with Sprint in advance, in that case, you can pick more work while it is always better idea to increase your velocity and focus on tech debts, testing, and quality practices. You can even spend time on learning which is usually way more important than we usually think
Let’s talk about agile retrospective in this article
No matter how great your team is, there is always scope to improve and get better. The retrospective is a way to accomplish this periodically. The main focus is to look at what is working and what is not? Further, what are the action items we have based on our learning? The core focus of retrospective is a continuous improvement which is one of the core philosophy of agile.
The primary agenda of this meeting where every team member is expected to bring their points are
What worked well?
What did not work well?
Action items to improve the process (Mainly action items are result of what did not work well)
How to do it
Set the stage. Invite entire team to a meeting (Scrum Master, Product Owner, Team and Customer if possible)
Give 10 minutes for everyone to enter their points towards 3 agenda items stated above. The recommendation is to use a tool (For instance noteapp) and send this to the whole team in advance to enter their points. This would save time for a team in meeting and moreover give enough time to team members to think and state their points.
Start with talking about previous retrospectives action items. Close the items which are accomplished.
Talk about what worked well, appreciate people and motivate the team to continue utilizing the best practices.
Discuss what did not work well and come with action items
Assign owners to every action item.
Close the retrospective while action items to go to action item register.
Typically it should happen after every sprint and should last between 30 to 60 minutes.
The whole team should participate.
This can be considered as “lesson learned” meeting. The notes can go to organizational process assets (Remember “PAL” or “Process Asset Library”).
The owners must be assigned to action items. The next retrospective should start with open items of previous retrospective meetings. I have seen, individual teams have excellent ideas while post retrospective nobody really thinks about it.
One of the recommendation is to have a retrospective of retrospectives to make it better.
Don’t point fingers instead work as a team and support each other.