Go2Agile: Do Agile the Go2Group Way
September 27, 2019 | by Jobin Kuruvilla | Posted In Agile
Go2Group is a pioneer in Agile and DevOps transformation. With our approach to Application Lifecycle Management (ALM) that utilizes an Agile development philosophy coupled with our ecosystem of DevOps automation tools and platforms, we help businesses match enterprise application delivery speed and quality to modern pace of change.
Have you ever wondered about a magic formula to successfully implement Agile? Can Go2Group, or any other company for that matter, come in and turn ON the switch to enable Agile in the enterprise? Is there a product named Go2Agile that does it all?
Sadly, the answer is NO. Go2Agile is not a product. It is a way of implementing Agile, but one that has worked in multiple organizations, through the years of Agile explosion.
The problem space
Agile is a process that can solve many problems that existed in the old, waterfall style workflows. But it introduces problems as well. When you start to implement Agile, you run into two kinds of people.
- Those who love Agile. No, not just the Agile coaches. This group also includes the management who wants to transform the organizational culture, the “just certified” Scrum Masters, Agile evangelists (hello there!) and so on.
2. Those who hate Agile. Read developers/consultants/anyone who has to give a status update in the standups! No, that may not be accurate. There are technical people who understand Agile and want to be part of the success it brings. But there are also those who are frustrated with the nuances it brings, due to a lack of understanding of the process or the emphasis on details, which in turn hinders progress.
Of course there is a third kind who just goes with the flow or a fourth who does Agile because it is “cool”. But the success of an Agile implementation depends on winning over the second kind by figuring out the aforementioned nuances that are obstructing them from doing their daily job. It might also involve making subtle changes to the process put forward by the first kind.
A big step in that direction is to understand the most common gripes about doing Agile. A fascinating article on this can be read here. While I concur with Mr. Cagle on many points, a lot of this can be fixed by making subtle changes to the process. In other words, being agile about how to implement Agile is the key to success!
The common gripes and working around them
Let’s face it. Agile is not the solution to all the problems. But it does work well in many cases, if done correctly. Some say that the probability of two Agile coaches agreeing on something is less than the probability of two parallel lines intersecting! While there is some truth to it, a lot of the common working issues for Agile are well-documented and there are hundreds of articles already written on addressing each of these issues. The following is neither an exhaustive list of issues nor a comprehensive study on how to address them. These are just some of the most common issues this author has come across, while working with various Go2Group customers, and some tips on how to adjust the process in order to shift the focus back to delivering software.
Scrum vs Kanban vs XP vs ..
Yep, Agile is not just Scrum. Let’s first get that out of the way!
“Agile describes a set of guiding principles that uses iterative approach for software development, while Scrum is a specific set of rules that are to be followed while practicing Agile software development.”
There are other Agile methodologies too. And there isn’t one that fits all teams. Implementing Agile in an organization doesn’t really mean picking up one methodology and implementing it across the board. A critical part of implementing Agile is to work with teams to identify the methodology that best fits their work culture. For example, a development team that builds a product might find Scrum best suited for their workflows whereas a support team (Production support, Tools teams, DevOps teams, etc.) might find Kanban, which emphasizes on continuous delivery with constant re-prioritization, more suitable. Working with the teams to find out what best fits them is half the battle. If you don’t get it right, teams will most certainly end up struggling to live up to their commitments.
You might want to ask the following questions before you go one way or the other.
- Are your requirements well-understood?
- Are you a well-organized team who can perform all the sprint ceremonies?
- Are your stakeholders involved and require a quick feedback loop?
- Are you able to deliver small chunks of work that can be demoed at the end of an iteration?
If so, you might be looking at a Scrum team. Start talking “Scrum”!
- Are your tasks constantly re-prioritized?
- Are you constantly releasing? Daily, weekly?
- Do you have too many unplanned activities? For example, production outages hampering the current queue?
- Do you hate Scrum Masters constantly asking for status updates?
Well, the last one maybe a cultural change that you can figure out, but you might be looking at a Kanban team if you said yes to the second set of questions.
You might also be able to implement a combination, like Scrumban, or even go full throttle with Extreme Programming (XP), depending on what works best for the team. But, in the end, there is no single solution that works for all the teams in a big organization.
Story points vs time
Yep. Before you work out the magic formula to convert story points to time and vice versa, you must realize that they are not the same.
Traditional teams have always estimated in time. It is common to estimate that a certain task will take ‘X’ hours or ‘Y’ days. And this might work even for a Scrum team as they transition into Agile from Waterfall. Most Agile tools support using ‘Time’ as an estimation metric. Having said that, there is a reason why ‘Story Points’ are hugely popular.
- Story points are a relative estimate of work. They are based on difficulty, not time spent. That is why they are measured in T-shirt sizes (S,M,L,XL,XXL), Fibonacci series (1,2,3,5,8,13) etc. Two stories that have the same estimate (say L) don’t necessarily take the same amount of time. They both are in the ‘L’ bucket because they both are bigger than stories in the ‘M’ bucket but smaller than the ones in ‘XL’ bucket. They are likely to take similar amount of times but one could take four days whereas the other one takes five days.
- Story points are not tied to an individual. People take different amount of time to finish a given amount of work for various reasons. For example, an experienced person in the team might finish a task in four hours whereas a new hire might take eight hours for the exact same task. When you estimate in points, the story falls in to the ‘S’ bucket or gets 1 story point and the difference in hours matters less. Switching tasks between individuals also is much smoother for the same reason.
- Story Points don’t need the precise estimation required for time. Since it is a relative estimate, the team is not bound to provide an accurate number like four hours or eight hours. And that helps to better accommodate the unexpected complications while working on a task.
- Just like the individuals estimating differently, teams estimate differently too. And they have different velocities as well. Estimating in story points gives the teams a space of their own, as opposed to time which will eventually draw unwarranted comparisons between teams.
There could be multiple other reasons but these are the few key ones that should be considered before adopting one technique over the other.
“You told me so!”
As Mr. Cagle explained very well in the aforementioned Forbes article, creating software is not always predictable like setting up an assembly line. That is one reason why the July 2013 Scrum Guide started using the word “forecast” instead of “commitment” while estimating stories in sprint planning.
Also, the estimation is done by the team, not an individual. Be it using planning poker, or using old school vocal votes, the team owns it. The dependencies and complications are to be identified during planning and the onus is on the team to do better in the next sprint if they get it wrong in the current sprint. Product Owner and Scrum Master are part of the team and share the responsibility of their team missing out on the “forecast”!
The art of story writing
Right. If you haven’t got it, writing stories hurt. But, it isn’t supposed to hurt. And, believe me, the template of the story is not that important! Of course, you can have your “As a.. I want to.. so that..” templates like the following example, but it is up to the team to agree on a format that works.
As a developer,
I want to get some clarity on what I need to do, no matter how you say it
so that I can go do some coding!
Well written user stories are important because they help everyone. Instead of making it a complex process, you might want to concentrate on the basics:
- Make sure you capture the “Who,” “What” and “Why” in one way or the other. Depending on how important it is for the team, you might even want to have custom fields on your story tracking system that capture it!
- Keep them short enough to fit into a sprint. When the story is too big, that is when you run into the complex, unpleasant discussions around splitting the story vs falling over to the next sprint.
- Try not to have a single story touching multiple application tiers, teams etc to reduce dependencies.
- Define the hierarchy. Epic -> Story -> Task -> Subtask or whatever that works for the team and decide how they fit into the sprints.
- Involve the whole team. Not just PO, Scrum Master and Tech Lead.
Acceptance criteria and definition of “done”
Depends on who you ask.
Story of some teams!
In order to avoid so many awkward conversations during standups and sprint demos, it is important to have a proper definition of “Done”. For example, some teams will define the story as done once the unit testing is finished whereas for others a story is done only if it is tested and approved in UAT. For some high performance teams practicing continuous deployment, a story might be done only after it makes its way into production! If the PO and team members are not on the same page on the definition of done, practicing Scrum becomes way more difficult!
Equally important is to have proper acceptance criteria defined on the stories. You don’t want to deliver a Toyota when the customer is expecting a Benz, do you? A story is done only after all the acceptance criteria are met. A good AC should be from the user’s perspective and should be testable. And it is important not to alter the ACs after the sprint has started unless agreed by all parties, because it changes the scope of the sprint.
Standups are meant to be short and sweet. They are meant to connect the team on:
- What everyone did yesterday
- What everyone is planning to work on today
- What issues are blocking the team
But, at times, things are taken too literally!
While there is nothing wrong in standing up during a standup, or even doing a plank to reduce the overall time, the meaning is lost if it turns either into a monologue or into another planning session. You have to find the right balance where the team gets a proper update from everyone and also resolve any blockers that is on their way. If it takes too long to resolve an issue, create follow-up meetings or action items and move on!
Collaboration among the team is also another key area for the success of the team. Team members shouldn’t have to wait until the next standup to resolve a blocker and instead should be encouraged to reach out for help throughout the day.
Retrospectives are not always fun, are they?
The purpose of retrospective is to find out how the team can do better in future.
- What went well?
- What went wrong?
- Were there any surprises?
- What can we do differently to address the things that went wrong and be better prepared for the surprises?
A good retrospective covers all this in a safe, blameless environment. Teams should be allowed to express their thoughts and action items should come out of the areas of improvement. Keep in mind that the whole exercise can be quite painful when the focus is on the ‘bad’ and the reasoning falls on deaf ears.
Meeting the sprint goal is the responsibility of the entire team, including PO & SM. Agile ceremonies like Standups and reports like Burndown charts provides early visibility into potential failures. It is up to the teams to catch them early, resolve them and move on. Retrospective is a place to work together and identify the areas of improvement to make future sprints more predictable.
And, maybe, use a good tool to make it more fun. But make sure that the team has a say in the tool to use!
That’s right. It is never the right time. And grooming the backlog is usually a backlog item! It is a nightmare, especially if you don’t get the art of story writing (See #4)!
But, backlog grooming is a secret receipt to successful sprint planning for many reasons.
- The time you spent on grooming is not really time lost. It will eventually save you time from the never-ending sprint planning sessions.
- Grooming helps to check the relevance of a story. For example, a story that was well-written two weeks back is probably not applicable anymore or might need some adjustments in the Acceptance Criteria.
- Grooming helps to keep the size of the backlog in check. If you have a backlog with 1000 stories, as opposed to 100, maybe you have a problem with the capacity.
Having said that, putting a few guidelines in place will surely help. For example, never spend more than ten minutes on a story. Arrange a follow-up if you need to flesh out the details. Also, having short frequent meetings might be better than a two hour session every two weeks.
No matter what the problem is, a lot of the issues have two things in common:
- Misunderstanding of the concepts. There are gray areas to Agile but it is harder when teams think that Agile means Scrum and that Scrum is nothing but Waterfall cut into sprints!
- Lack of agreement between Product Owner, Scrum Master and Team members. It is important for all players in the team to be on the same page and anything less is the prime reason for the failure of Agile teams.
I have seen well-oiled support teams pegged back because they were forced to do Scrum. I have also seen the quality of software improving drastically when teams switched from traditional waterfall model to Agile. Granted some teams might be doing things in an unconventional manner, but that should be okay if there are able to deliver quality software consistently. The priority is, and always should be, to find common ground and keep going.
In short, be agile about implementing Agile. And, remember, Together Everyone Achieves More!
Editor’s note: Contact us to learn more about how we can help you implement Agile across your organization.