Agile software development or methodology or framework refers to time boxed, continuous iteration of development and testing to build software where the solutions evolve throughout with incremental development via collaboration among self-organizing teams. Agile helps organizations to expertise and respond to continuous change and make them able to do more.
As shown in above diagram, the vision and feasibility are most important factors to be considered before starting a project. In this phase, we identify whether we should consider doing a project or not. Some of the questions need to be answered in this phase like what is going to be ROI (Return of investments) for a project? How do we get funding? Is it worth taking risks? Staffing? what is the value the project bring in? etc. You use this phase to break the idea into individual functionality items called features or user stories. If this looks positive, the next step is to create a product roadmap document.
The product backlog is created leveraging the product roadmap document. The release planning results in release backlog. The individual sprints are defined to accomplish upcoming release goals. The Agile Roadmap blog defines the entire project in more details.
One of the powerful retrospective getting very popular lately is Sad/Mad and Glad. Many organizations don’t even conduct it as they are afraid to talk about employee challenges or too busy to do other things that they don’t have time to focus on employee morale. There are obviously pros and cons but making it work truly helps you to achieve more. In my personal opinion, the number of positives what you have with this retrospective is far higher than challenges hence it’s worth doing it.
Your team and your presence
Sticky notes (Three colors)
Open minded motivated teams
In this retrospective, you ask your team to get into a room. Every colored sticky note represents Sad/Mad or Glad respectively. You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!
You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!
You can start your meeting with a positive note. Ask individuals to participate freely and openly. Once the stage is all set, you can ask every individual to write up the areas what they are happy about it (Glad), don’t like it (Sad) or frustrated with it (Mad) on different color sticky notes. I always recommend individual team members to write their names on each sticky note else there are good chances that it would become a political battle. You should always give an option to do go with anonymous though.
I have seen instances where team members just write some crap either because they did not have good appraisal last time or not in line with others due to personal issues. If you find an item which has something written in sad or mad while an individual who wrote it is not willing to even talk about it then you can very much assume either that’s fake or written with the wrong intention hence discard it. There are some people very shy and not willing to open at all. They should go to their manager or who is driving sad mad/glad to discuss the area of concern. Just to avoid the frustration as manager, anything written as an area of concern and individual is not willing to open up personally or with the team, you can safely scrap it.
Once everyone is done with writing, spend an hour or so reading every item and discuss that with the team. Remember the goal is to share as much as information about the issue and gaining more details around the problem while not fixing the problem there itself. This would be good input to take it forward as employee happiness and moral is very critical to agile success.
Things to remember while doing Sad/Mad & Glad:-
You should be reading every item loud or make it visible to every individual unless there is a derogatory remark which is not acceptable.
Team to think of the success of team and project rather considering this as revenge material.
Everyone must open up. If you don’t have guts to talk about your challenge then don’t even write it. You are just creating a FUSS which is either not true or you don’t know what is this the right forum to talk about it.
Refrain from making comments about an individual if you don’t have supporting material. The world is not perfect. The goal is to identify the improve system over making it worse
Should not be anonymous.
Don’t abuse it. It is conducted to the best interest of an individual and improves as a team. It should never be used as a tool to fulfill your political battle.
Not every problem can be fixed eventually. Somebody writes that I don’t feel like working doesn’t mean you would allow him to sleep in the office.
Don’t try to fix the problems during this retrospective.
Constantly read the issues/concerns raised and strive to fix as much as you can. Provide updates to the team around the issues you committed you would work on.
The benefits I see with this retrospective are:-
Gives lots of motivation to the team when going over “Glad” items.
Give an opportunity to an employee to express their challenges.
Bring in open culture
Reduce attrition as you really know challenges and definitely a lot of which you can work on.
It gives 360 views in terms of how the teams are progressing.
One of the biggest “Glad” item I would say is that your organization is conducting it.
The challenges I see are:-
It may become a political battle if your team is not mature and willing to go for an anonymous survey.
Excessive sad mad and glad would unearth issues which are not really problems while making other team members think it’s a major problem.
Sometimes very happy team morale goes down as well as when you have an opportunity to think about negatives, you feel like writing it and further “law of attraction” does its job.
What I was written must be addressed and fixed “Myth”. You may not like the tile color in the washroom but that cannot be really changed.
We all hear that Agile teams need to be self-organized. However there is not enough talked about what it means by self-organized. In this article, we will discuss the various qualities of self-organized teams.
High levels of personal responsibility
Self-organized team members are highly responsible individuals. They value the importance of their contribution to the overall success of the project. Because of this they do things on time, be available, and develop great relationship with other team members. When things are not happening as required, they take responsibility and do their part to get things done.
Put team first Team work
Being organized also mean being able to see the bigger picture. Self-organized team members always put team before them. Individuals have great respect for a combined democratic team decision than an ego-centric decision.
Openly ask and provide help Help me
Everyone is a learner and beginner before being an expert. So self-organized team help other team members for their short comings and also openly ask for help. They coach their fellow members and give them time to improve. As there are no shaming/blaming any one can ask for help without fear of being criticized.
Hold each other accountable
Pointing the finger
Self-organized teams are mostly a closed group and they have high levels of emotional security with each other. So they “call spade a spade” openly and bring up crucial topics and iron them out sooner. This not only happens at the same org level but they have no fear to hold a superior accountable.
High standards Its a Promise
They agree upon nothing less than the best. Team members agree on a common set of standards which they continuously improve. They seek advice from industry veterans, architects, managers and anyone who can help improve themselves and the team.
NO managers required
They understand the strength and weakness of not only themselves but also other fellow team members. By respectfully and openly talking and holding each other accountable, team gets better at their game. Also self-organizing teams pick and choose who gets into their team. They often interview new individuals and sets very high expectations from the day one. Instead of managers, self-organized teams rather require a coach who will guide them from outside.
Maturity not only comes with age, but also with the company of highly mature individuals. Self-reinforcement of high standards and accountability makes them mature and the team members self-esteem is often very high.
Enjoy the company
Last but not the least, self-organized team enjoy their time together. They combine specific business meetings at various places where they enjoy the time and at the same time business gets done. They make fun, laugh, and merry together so that life becomes less stressful.
A switch from waterfall to agile project and suddenly you would start seeing whole new world. Is this shift complicated? How can I be successful as manager in agile project? How does it defer from traditional methodology? And there are many more questions which every manager who starts with agile project or managers already part of agile project come up with. Most importantly what is my ROLE? Lets explore
As a manager, when you get into a project you want to manage the day to day deliverables and processes but wait that’s a job of a scrum master, you move on to prioritize the work but that’s again product owner owns. Wow, then you jump on to assign work and get involved in day to day activities but wait again, isn’t your teams are self-organizing?
By heart, I am a software engineer. Can I code? Off course you can if you don’t have any other work and moreover you are expected to become a team member. Frustrating, well yes and no. If you are quite adamant and not ready to unlearn some of the traditional practices as manager, you would be biggest bottleneck in getting your project successful. You can’t do many things in agile while you can control everything by keeping some distance while taking complete ownership.
As a manager, I would suggest you to do the following
Motivate team – Constantly encourage your team members. Agile focus on every individual and a motivated team member can do wonders. If you are thinking of spoon feeding agile member then either the member has too many challenges or you are not a right manager.
Celebrate victories – Find an opportunity to celebrate your victories. Even if that are small as every celebration would enhance your team motivation and bring in lots of energy to system.
Focus on business priorities – Constantly focus on your business priorities, contribute in vision, drive vision by ensuring work gets done, keep abreast with business demand. Learn domain and make your team gain expertise over that. Build a model to train new joiners quickly. Encourage collaboration and encourage teams to discuss the business.
Be open – This is one of the biggest challenge I see in this industry. You don’t want to hurt anybody and with that you always go with giving positive feedback. Remember the areas of improvement and constructive feedback helps an individual to grow. You are supporting short term growth by killing his/her long term growth as well as organization priorities. You need to constantly strive to build your team and focus on every individual to be successful. More you focus on people, better off your results are. Rate your people as they are. You need to motivate your high performers and bring you low performers to get better. Always remember that you need to get better constantly.
Generate Metrics and constantly monitor them – The world is not perfect place. Teams which are doing amazing, may go down. Constantly monitor productivity, prod issues, defect rate and whatever is important in your organization.
Trust team and encourage the culture of trusting people – In my experience, if you have an average team, and that team trust each other and ready to support each other, they would end up doing much more and better compare to your star team where you see conflicts. I have seen multiple examples in past where the whole team gel extremely well and the result you see are outstanding. Not just project did the best in those scenarios while the whole team has gotten bigger rewards and great careers. The dedication to team result in delivering values. This holds true all the times.
Invest in resources – Hire best talent. Further send them for trainings, Encourage cross KT culture, plan their travel if their teams are in different country city, constantly keep in touch with them and make them feel that the org does care for them. Many a times in bigger organization individuals are lost while it is primary responsibility of a project manager to ensure they are being taken care of. One of the tool I used heavily is to ask individuals their aspirations and constantly seek opportunities to fulfill them. You may not be able to do it all but creating a path is kind of easy. In fact, many a times I see individual aspirations are so easy that it can be fulfilled in no time and little effort.
Process improvements – Let scrum master handles processes while constantly review to see what improvements can be made further. Improving on test coverage, adhering to standard practices, encouraging people to take risks etc. For instance you see all retrospective items are great while after a meeting we don’t do anything about it (Unfortunately most agile team has this challenge). Well, here you can have action items and ask team to assign that. The next retrospective should start with older action items. You can always work with scrum master to get processes better.
1×1 Meetings – This is very powerful tool. As a manager, I would strongly recommend you to keep talking to team members. Appreciate them for their great work. Constantly provide feedback on areas they should get better. Understand their perspective and identify action items for you. Make yourself available for team all the times. I am being often told by managers coming from traditional model that don’t be easily available for your team as you may end up doing more and people won’t value you. I am completely against of that idea. I think you should meet up your team as much as you can.
Empowerment – Find right people and empower them to do certain things. Build your next set of leaders. Trust people. If you manage multiple agile teams then build leader within each team and empower them. Practically you shouldn’t be very busy all the times. You should be available for your team as soon as possible when they need you.
Improve system – You should be constantly looking at everything in the system and find opportunities to improve them. Improving productivity, quality, trust, competence, delivery, processes and many more.
Seek challenges – The seeking challenges is always better option over embracing challenges. You should be constantly seeking challenges and building the same culture around that.
Fun place to work– Create an environment where everyone feels like coming to office. There should be lots of fun. Believe in starting your day with fun and it should be throughout. Don’t have a constraint that I would allow you to have fun when we achieve something. Although you do celebrate every victory but fun is something should be there all the times.
Always remember that things which you can do directly, that’s great while things or tasks which agile doesn’t allow you to do it, get yourself involved indirectly and get them accomplished. At the end of day, your biggest priority is make your team successful. If you can achieve that, rest all fall in place.
The story point is high level estimation based on complexity before the work begins on story while the hour based estimation is just more concrete estimation where effort is represented in hours. The amount of work a team can accomplish during a single sprint is called Velocity. It is calculated at the end of Sprint by adding all the story points which are done-done.
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of theSprint by totaling the Points for all fully completed User Stories
Now the question is how does story points relate to time and this is certainly one of the debated topic among sprint teams and I see confusion all around. I heard from individual team members many a times that story point can never be related to time in any way. One cannot say 1 story point equivalent to 2 hours or 5 hours or any other number. The second statement is right while this creates a notion that story point has no relation with time. When you have 3 story points, it could take 3 days or up to 50 days. This doesn’t seem right and this is actually not RIGHT. “Whatever time it takes is fine after-all one is putting on effort” effect is what visible .
The reality is, the story point states EFFORT. The estimation for team member X can be 10 hours for 3 story points while other it could be 20 hours. The moment you say effort, it is size. But the size is relative. Hence it proves the point that it is not exact hours while it’s relative hours. The estimate is for team and they should be able to say what is the biggest size in terms of story points can be picked which would be done in sprint. Moreover if we say, team velocity is 40 story points that means we can complete 40 story points for this team in N week sprint.
If one doesn’t want to relate this to size at all, then I suggest them to stop doing estimation as in that it case it would be just waste of time. Typically a story point suggest min and max time which might be taken to accomplish that story. For instance 3 story point for team P means effort between 3 and 5 days. It could be plus or minus but the point I have is to have some indication with respect to size.
I have seen individuals just change the story point for a given story if they can’t complete the same in stipulated time. I understand the estimation was not done right or probably we might not have done estimation but adding/changing story point or hours post the work is being done is pathetic. It completely wastes the time spent on estimation and further we lose all the value gain with estimation. This practice is primarily meant for inflating numbers to have better reports. This MUST be stopped.
I have been often asked that the team is not able to predict well because they are new or may not be competent enough to find the right story points. How should we handle that as it is important to be predictable as you can’t run the business in vacuum? When your boss or business ask how long it takes to complete the effort, you still have to answer probably by looking at release planning and estimation. This shows another point why we have to relate the effort to hours (Not the exact) and here min and max does the job.
As we are talking about story points, there are many teams who would just add story points to story while for individual tasks they don’t assign hours. The burndown chart in that case is driven by task (Task based or hour based) which is in a way weird because you suddenly see ups and downs. The whole value of one of the most critical artifact in agile is not being materialized. The planned and remaining hours is important in individual tasks.
There is enough motivation I have to write this article as the whole intention is to answer the questions which I have been asked multiple times pertaining to sprints I dealt with.
Some of which are listed below but not limited to
– How can we ensure sprint success?
– Should we do more or less?
– Why continuous improvement?
– How can I be successful? How can I grow faster?
– How to get better at estimation?
– Am I following the right set of processes?
– Is pairing good and how should we pair?
– Am I being heard? Should I challenge people? What if the team is very senior compare to me?
– The standup happens in the evening because of the offshore and onshore model? How to make it effective?
And the list is endless.
Let’s assume you are already in sprint cycle. One of the important questions is how do you provide an estimate for items which are already prioritized for sprint? The majority of newbies teams with limited exposure to agile struggle due to unknowns during mid-sprint which was not accounted for. The estimation might have given with many assumptions. The predictability is the biggest concern in most agile teams. One of the easiest ways is to pre-groom stories well in advance. Typically for two weeks sprint, I encourage the team to spend 10-15% of time daily during the second week of a sprint to get as many details as possible for next sprint stories, create tasks, identify dependencies, quick spikes to find out the feasibility.
The typical myth most people have that we should be adding only tasks having business values while it might be a look good factor for product owner but from a developer standpoint, this is something we should avoid. In addition to functional and non-functional requirements, a team should add testing, documentation, and everything that they would work on as a task. This given better clarity and sharing of work.
When you constantly spend time in grooming next week sprint story, you are very confident how much worth of work you can do it in next sprint when you get on to sprint planning as your estimates are good enough with confidence that what you are going to build. As this practice continues, there is a point which comes approx. in 3 to 4 sprints where the team doesn’t even pick a work which is not clear.
In summary, when a team starts with sprint, during the planning meeting, everyone talks about stories and tasks (Tasking is done). The goal is to add/remove items might not have been considered and provide estimates. The commitment is made with lots of confidence. You can never avoid unknowns while the chances of getting it reduced significantly increases.
Just to prove above point, once I have enforced SRS (Software Requirement Specification) in agile where it must have to be created and approved before planning a day in order for that item to be considered for planning. The team productivity dropped for 30-40% in first two weeks to get settled with new process inception and spending time in creating a document while as the time passed, the team who was not confident in doing 35 story points, hitting close to 60+ story points. All that happens in less than 4 sprints. Worth it!! Isn’t it?
This approach is phenomenal when the team is co-located while teams which are not, it can be slightly modified. For instance, the team at location x can pre-groom few stories and location y does the same with another set of stories.
There is another interesting thing which I have seen in offshore and onshore are sharing the same stories. The challenge is what I work (assuming I am at offshore), I need to hand off to onshore and vice versa. For 6 day worth of story, I and my counterpart need to understand what other person has done. The wastage of time in handoff and further understanding work done by counterpart every day by both ends adds extra hours.
I have seen instances when a story which can be done in 6 days took more than 6 days because of the addition of another person. Sounds funny? Yes, it is. Even if in extremely positive scenarios, it would add 50% extra time. A lot of people think we can avoid dependency and everyone should know everything, while it is funnier that the horizon of learning is limited for an individual if you look at long term. I am not saying that we shouldn’t do that but we need to be wary of taking a right decision. For instance, if there is a production issue or a complicated story which we want more than one person to learn/work or a story must have to be completed in little lesser time. With these kinds of practices, trade-off is understood. Compromising productivity to achieve temporary priority is fine in this case.
When the team is aggressive, they pick more points and to make up that quality is being compromised. Or the team may not be able to do that, which is even worse as it demotivates the team. I always tell my all teams to start with less (less than they think they can really do it). Further, as we progress, keep on taking more and more. The constant improvement is really important.
As discussed earlier, the pre-grooming or creating SRS very much fix this issue.
In order to have your sprint successful below is what I think are very critical
– Trust each other in team
– Give focused hours. Core working hours are really important
– Celebrate every victory
– Appreciate your team members
– Provide feedback openly
– Fail faster
The “I” factor usually becomes a challenge in many sprint teams. I will pick the certain specific piece and create dependency or I am more competent, and I would do my own over working with a team. The moment you see people like this in your team, get that fixed or move those out of the team. They just create a nuisance and spoil team culture. This is just a myth for an individual as it’s very easy to replace anybody in agile. The only worry, I see here is spoiling team culture.
As an individual team member of team, the success of him/her is
Constantly learning, learning faster
I have seen less competent team while better at supporting and trusting each other ended up doing much better in terms of quality, quantity and achieving business goals compared to high experienced teams with team culture lacking. Agile is all about self-organizing teams which move up in ladder by helping each other to grow. It is so beautiful that everything is visible and individuals with “I” and “We” just do not grow. If you are not able to openly give feedback to your team member because you are scared, you would end up being just mediocre. I do less because sprint success is important and does it matter if I work just 2 hours a day because I am completed all the work I planned. Sounds familiar?
Another interesting observation what I have from some of the developers is if I don’t contribute it is anyway not visible because I can show I am pairing or stuck on complicated issues or whatever. It’s is a just wonderful myth. The agile gives so much of clarity that everything is visible.
When it comes to releasing software, I would say release as many times as you can. This would force you to think a need of having lots of tests. Again one of the common challenges is, most teams focus well on the unit test while they hardly create integration test. That is bigger killer in long run. A lot of great teams are given 20% to 30% time in a sprint just to refactor code, working on extra tests which are not there or working on nonfunctional requirements. The challenge is if it’s not planned, it doesn’t happen. The human psychology must have to be addressed. If I am given a work on Monday and I am expected to do this by Friday, I would do that on Friday even if I could have done that in 2 days. In addition to that when you have a task it has to be done.
How great self-organizing team you have, it is always good to add work in sprint board.
The fear is another cause of doing less or not doing RIGHT. Many times teams are afraid that they may not be able to complete the work hence they pick less and even though work gets completed in advance, they keep picking less. The extra time remaining is good for learning new stuff and working on tech debts. 1/2 day or one-day learning is decent for two weeks of sprint while for tech debt and other stuff, planning results better outcome. When the team trusts each other, they as the team always take credit for success and accountable for failures. It sounds better. Indeed it is. Agile encourage you to fail while with every failure you should learn and avoid repeating that mistake. When you are working on existing complicated product, and while working on the story you see there is an opportunity to fix existing bug or refactor some code, I would say you should do it. Or plan to do it ASAP.
If your team or PO is discouraging you from doing that, talk as a team. Your goal is not just to fix issue what customer reported while you should be constantly striving to make your product better. The priority can be discussed and trade off can be identified while If you don’t do it, it would never happen.
Let’s talk about scope creep. The scope creep is nothing but change of scope or change in requirements
If it’s in middle of sprint, there are only two ways to manage it
– Push it to next sprint
– Remove the same amount of work to pick new work (Do it only when it’s VERY important). Agile completely discourages it but when there is a prod issue or something similar to that sort pops in, you might have to take wise decision)
If it’s outside of sprint
Agile is excellent, it depends on the SOW you have signed. Primarily, you can take something out or you can add another sprint to your total number of sprint or whatever you have agreed on.
I personally don’t allow a team to pick work which comes during the middle of the sprint. It creates lots of confusion. Until and unless it is extremely important, you should not be picking it up. The extreme urgency like prod issue comes from customer etc. Many of the things can be planned by keeping some 10 to 20% of bandwidth to manage these support issues. If there is a huge work which would spoil the sprint, the best thing to do is to start a new sprint.
Another practice which I feel goes pretty well when you have offshore and onshore model, is to have quick sync meeting in morning. Typically standup happens in the evening which is nothing but post-mortem or status meeting who is attending that in evening. It doesn’t have the benefits of stand-up at all hence meeting in morning for such team adds lots of value.
The demo and showcase are very important, and I always prefer a practice of showing it to team and PO as and when it’s available. How great the requirement elicitation is, there are always things which get missed. I have seen teams doing Agile with waterfall model and I call that as “waterfall agile”. Most of the team members work on development for first 70% of days and in the end, the focus is on QA which is ridiculous. Ideally, you should work on development, testing, and showcase. If possible push that code to prod as soon as you can and don’t wait for the whole sprint to get completed. There is an exception to this is when you have bigger products and many customers are using it. This kind of scenarios you should be looking at a number of tests you have and what kind of dependencies to be addressed.
Agile is really very simple hence it doesn’t allow you to do too much tailoring, unlike waterfall method. Every process is simple but it has to be done diligently. You don’t work as individual while you work as a team.
You must earn 21 PDUs (Professional Development Units) to be able to appear for this exam. You are expected to earn at least 30 PDU every three years in order to main the status of this certification.
PDU – One PDU can be earned with one hour of activity (training). As per the PMI “The professional development units(PDUs) are the measuring unit used to quantify approved learning and professional service activities.”
Agile – The agile means able to move quickly and rapidly. Precisely the ability to both create and respond to change in order to fulfill the fast paced dynamic business environment refers to agility.
Agile software development refers to a set of protocols for building software under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, early delivery, evolutionary development and continuous improvement, and it also encourages rapid and flexible response to change.
The big question is when to use Agile. The world is moving towards Agile and one of the study shows that majority of companies would be very much Agile by 2020 and if not, it would be very difficult for them to survive. Although Agile adds value to process stream in most case while there are certain situations where it may not be apt.
While moving towards agile, one should evaluate following answers to below questions
Requirement Definition – Changing or Constant
Experience and Skills of a Team – Highly skilled or Newbies
Change – Frequent changes or Less
Resources – Dedicated or floating
Timelines – Fixed or Flexible
Documentation – Less or more
Customer Involvement – Continuous or Intermittent
Physical Location of resources – Co-located or Distributed
The mission critical applications or products probably still better be on waterfall or traditional model. Probably the 8 points mentioned above should be given a thought before taking a decision of choosing the right set of processes