Practical Agile

Photo by Daria Nepriakhina on Unsplash

If you have been practicing agile for software development you could be aware of the agile manifesto and the 12 principles behind the manifesto. The software development landscape has undergone constant change since the manifesto was created. Keeping up with the evolving technology and the gained experience. While the manifesto and the principles still hold true, agile frameworks like Scrum, Kanban, Lean and Extreme Programming and so on have been adapted to suit the current environment as well as the dynamics of the organizations and teams. Here I’d like to talk about the application of agile frameworks in real life based on my five years of experience working in large organizations that practice agile.

Scrum vs Kanban vs Scrumban

Scrum is based on short, structured work sprints while Kanban methodologies are continuous and more fluid. In my years of experience I find it hard to pick and diligently follow a single framework and be the most productive possible. In fact most of the companies that I’ve worked with or spoken to practice a mixture of both Scrum and Kanban.

In a Twitter poll conducted by Atlassian, 92% of respondents said they were practicing something custom and not “by the book.”

With Scrum and Kanban being the two most popular agile frameworks, is Scrumban the answer to modern agile software development? It’s to be noted that there is no official Scrumban framework. I guess if you were to mix and match the features of Scrum and Kanban in any form it can be called Scrumban.

What I like about Scrum;

• Scrum roles: having the product owner, scrum master and development team roles give some basic structure to the team.
• Scrum ceremonies: daily standups and restropectives are in my opinion crucial for the success of any agile team.

What I don’t like about Scrum;

• Time-boxed sprints: Honestly I don’t see the benefit of grouping work into time bound chunks. Plus the usual method of doing it using story points and team velocity is not really easy. While we certainly need a review ceremony to inspect completed items with the stakeholders, it does not need to be at the end of fixed intervals. It makes more sense to do it based on sets of features. So the review may happen anytime we complete a feature.
• Sprint goal: Teams may work on multiple features and different parts of a feature at any time. It may depend on the skills available in the team, priority and whether any task is blocked. Often times it’s hard to set a focused sprint goal. A sprint goal that says we need to complete A, B & C don’t seem effective nor necessary.
• Sprint disruption: Besides working on features and known defects, it’s not uncommon to receive urgent supports cases. And that can easily disrupt a sprint and we may not be able to achieve the sprint goal.

What I like about Kanban;

• Continuous flow cadence: Though this needs discipline among the development team to plan ahead to avoid running out of items/stories to pick. Having a lead for each feature that the team works on helps to ensure there is someone responsible for making sure there are enough work planned at any point of time.
• None of the things listed under What I don’t like about Scrum above are necessary.

For me, Scrumban ftw!

Scrum master

Photo by Parabol on Unsplash

Scrum masters are the champion of scrum, and agile in general in any organization. As per the scrum framework there should be one scrum master per team. In my experience there is usually little need for a dedicated scrum master. Scrum master is a role that can be shared by members of the team.

While the development team is suppose to be self organizing, there is usually one member who is an engineering manager or team lead, who communicates with the stakeholders, helps to prioritize work, makes high level technical decisions and in short holds the team together. In my opinion this would be best person to wear the scrum master hat.

However it’s not necessary for just one person to take on all the responsibilities of the scrum master. Some responsibilities can be shared by other members. In our team for instance each of us developers would take turn hosting the sprint retrospective. While the developer leading any feature would be in charge of the sprint or feature planning.

Sprint Retrospective

A retrospective is anytime your team reflects on the past to improve for the future. So the sprint retrospective is a great opportunity for the team to look back at the processes and events that occurred during the particular sprint and plan ways to increase quality and effectiveness.

While it’s common to reflect on the things that did not go well so they can be improved for the coming sprints, it’s equally important to talk about the things that did go well.

Celebrate the small wins. Acknowledge the effort put in by the team members. Use the opportunity to thank.

In our team we practice giving kudo cards to acknowledge any effort that deserves a special mention. This don’t need to be something extraordinary. It can be something as simple as helping a new member get up to speed, or investigating some common issue, or if they went out of their way to help someone.

A study by Workforce Institute to explore the roots of day-to-day happiness in the workplace showed that;

• Receiving a “thank you” from their direct manager (55 percent) nearly doubled that of public recognition of a job well done (28 percent) even if the public recognition is tied to rewards such as a gift card or company award.
• Receiving positive feedback from fellow employees at all levels gave the highest sense of satisfaction, with 70 percent of employees saying it provides a boost.

Switch up your retrospective format. If you keep using the same format over and over again your team is bound to become bored with that rinse and repeat approach. Switch things up and keep everybody on their toes. That will keep participants more interested and engaged. There are lots of ideas on the net. You can also play games. SpaceTeam is one of the games my team plays. It’s a fun short game that teaches teamwork and cooperation.

Pair programming

Photo by Alvaro Reyes on Unsplash

Pair programming is one of the key practices of Extreme Programming(XP), an agile software development methodology introduced in the 1990’s. With XP, most development work is done by two(sometimes more) developers working side-by-side to code together. This approach is designed to optimize quality due to the built-in validation mechanism that is expected between two developers, which contribute to a single set of code.

While XP is not as prevalent as other agile frameworks, pair programming is a common practice in the wider software development community. And having done a fair share of pair programming myself, I would say that incorporating pair programming into no matter what agile framework you use is a great idea. But you need to be careful about how and where you use it.

Where pair programming works

• Pairing a new member of the team with an established member for a limited period of time helps the new member to get familiar with the team’s products, infrastructure and process and get up to speed quickly.
• Occasionally pairing a senior member with a junior is a good way to coach the junior. I myself have learned a lot by doing pair programming with more experienced developers and vouch for its effectiveness.

Cons of pair programming

• When two people of differing personality and programming style work together there can be clash in opinion for the right approach to take. This often happens when two developers of equal experience and capability are paired together
• Pair programming is an intense exercise. You need to be fully focused on the work at all times because you’re working with someone else. Taking occasional small breaks helps but overall it is an intense exercise and hard to do day in day out for an extended period of time.
• Every developer has his/her own style of setup and preference for the monitor, keyboard, mouse, code editor and any tool they may use. When you need to share the workspace with someone, the result is a setup that is less than ideal and this may affect productivity and morale.
• Most developers just don’t find pair programming over an extended period enjoyable.

In summary short periods of pair programming in certain scenarios is more readily accepted by developers and shown to produce great results.

Remote Teams

Photo by Charles Deluvio on Unsplash

Agile development was originally imagined for teams in close proximity e.g. teams physically located together in the same office. However since remote work is not uncommon now, we’ll have to make some adjustments to suit the new environment. After going pretty much fully remote due to Covid-19, I would say there were some challenges in the beginning but definitely agile is very much possible for remote teams. Even before Covid there were many organizations with fully remote teams successfully practicing agile.

A few tips for remote agile teams;

• Make it a habit to turn on the video during all conference calls. Remember that tone, voice and posture are significant part of communication. And seeing the faces helps to build rapport and a deeper connection and relationship.
• For hybrid teams even if one person is remote, do all the scrum ceremonies fully online with each person at his/her desk instead of those in the office being together in a room. This helps to prevent bias and those remote do not miss out on the side chats.
• Pair programming is still possible. You don’t need to be physically seated at the same desk. There are good online tools to facilitate pair programming. We used VS Code Live Share which was pretty good. There are many other similar tools that you can try and select one that you like.
• Remote work may also require new ceremonies. For example, keeping teams aligned with organizational objectives can be more challenging. This is easier for teams working together in person, where they can lean more heavily on organic interactions. But working remotely requires more purposeful and structured communication. In my team we’d have bi-weekly team catchup meetings to talk about the latest happenings in the company.
• Being remote there is little opportunity for the usual casual chat or coffee chat. I love these chats to get to know more about my team mates and others in the companies and it helps to develop connection and rapport. But all is not lost with being remote. We just need to put in more effort to make it happen. Having separate “social” channels in whatever communication app that your team and others use is a great idea. It’s where you just talk about anything and socialize. We use this channel to talk about current affairs, planning for lunch, joke and just talk nonsense. It really helps the team bond.

Conclusion

It’s perfectly alright to mix and match the features of multiple agile frameworks to suit the needs of your team or organization. What matters is that you are constantly improving your processes and result and able to achieve your full potential.