Blog


Ways of Sharing Knowledge On Agile Teams

To be agile and keep being agile there is one important aspect you should be conscious about: sharing knowledge.

One thing is that your team should be cross-functional. This of course does not mean every individual on the team should be able to perform each other’s tasks. Cross-functional teams are composed such that they have all competencies needed to accomplish the work without depending on anyone not part of the team.

However, it does not mean that none of the team members have overlapping skills either. In fact, we often refer to the T-shaped person as the ideal team member–having both a broad and in-depth skillset.

In addition, things other than just technical or tool specific skills are involved. Domain knowledge, knowledge about the architecture, coding standards, testing conventions and anything that touches how the team works every day come into play.

To be as effective as possible, I believe it is important that every team member have a base level of understanding of all these things. With a common architecture and domain understanding, every discussion about how to implement new features or how to makes changes to existing parts of the system will be a lot more effective and the outcome will be of higher quality.

Below I have listed some of my favorite practices, feel free to share yours, too!

Pair Programming

The ultimate way of sharing understanding and knowledge about the thing your team is working on is getting people together to work on it. Pair team members, let them sit together and struggle with the problems together by looking at the same code at the same time. Have your team rotate pairs every so often to widen the impact. You are not only getting instant feedback, but also cooperating on sharing knowledge about the code and the domain and architecture of the code. Pair programming is a great way to share knowledge and get a new team member up to speed as well.

The last few years, mob programming has come up as a popular alternative to pair programming. This involves getting the entire team together looking at the same code and solving the same problem at the same time. Looking at the effectiveness/efficiency diagram from “Agile Software Development” by Alistair Cockburn, the more closely people work the more effective the communication.

With respect to this, mob programming ideally should work even better than pair programming. How pair programming and mob programming match up regarding cost-effectiveness is, however, uncertain. Nevertheless, working closely enhances knowledge sharing. You should at least be doing pair programming, but make it possible to experiment with something like mob programming as well.

Code Reviews

Another great way to share understanding about what is being implemented is getting changesets reviewed by your peers. Discussing changesets through pull requests is a great opportunity to see which new features are being added to the system. It’s also perfect for looking at coding standards or whether or not the changes adhere to your architecture principles.

If you do pair programming you should let another pair review your changes so that you get a fresh pair of eyes on the code. Doing both pair and mob programming one could argue that code reviews are done continuously, but having a separate discussion when merging changes fosters a slightly different focus. Code reviews could of course be done on other blocks of code or parts of the system, but I find it easier to utilize something like pull requests to trigger code reviews on a continual basis.

Again, this follows the diagram given by Cockburn above. The closer you work, the richer and more effective the communication will get.

Lunch and Learns

As part of your normal pulse you should have regular demos and reviews of the things your team is implementing. While these demos and reviews are a great arena for sharing knowledge they should be part of your normal practice already. Lunch and learns, however, are a great arena for informal knowledge sharing. They are perfect for your team members to share new ideas, something specific about a recent implementation or going through concerns team members have about some areas of the system your team is implementing.

How Are You Sharing Knowledge On Your Team?

The practices mentioned above are far from an exhaustive list of things you can do to enable knowledge sharing on your team. They are, however, my favorite ones–and practices that I have seen work first-hand. By spreading knowledge in your teams, you will enable a base level of understanding of the code, domain, architecture, etc. Without this common understanding, it will be a lot more difficult to get the team to move in the same direction once the direction needs to be changed.

Do you have other good ways of sharing knowledge? Please let us know by using the comments below.

Deadlines in Agile

Imagine your company taking on a new project. It could be for a client or it could be an internal project – it does not matter. Along with every new project, there should and will be high expectations and lofty goals – and yes, a release date has been set.

"When” it will be done could come from many sources. It could be by some sort of estimation of all the work that needs to be done or it could be a wish or a guess – it could even be external factors deciding this date. Even if it’s internal project, somebody, usually the part of the organization impacted by the project, wants some way of knowing when the project will have this expected impact.

Deadlines are a reality. The question is: how do we deal with deadlines in agile?

Agile Principle: Sustainable Pace

One of the principles from the Agile Manifesto tells us: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Sustainable pace and deadlines? Traditional thinking usually leads to a lot of overtime when the project end is coming. This is when the project realizes that all those features that the project has committed to aren’t going to be finished by the set date.

To meet the deadline, overtime is used and that has all kinds of negative impact in the long run. You might increase productivity in the very short term, but the productivity lost after the deadline has been met is a great cost.

One hundred fifty years of research proves that shorter work hours raise productivity and profits, and overtime destroys them.

Short Iterations and Working Software

So, without overtime, how do we implement all those features that at project start were viewed as essential? The answer is that we in agile view essential features as something that is always changing based on feedback when iterating over that list of features.

There is just no way that anyone can know all the essential features up front. Short iterations and having working software as your primary measure of progress assures that when the deadline arrives, you are guaranteed to deliver a working product that is likely to contain features that are actually wanted by your customers.

A Shift in Mindset: Reduced Risk and Higher Precision

In a traditional approach, you are managing against the full set of requirements set out at the beginning of the project. You measure success against how many of these requirements are implemented.

Also, since testing the implemented features is a separate phase which usually doesn’t get the necessary prioritization, you might end up with a lot of features that actually don’t work properly. Not only might the features not work, but since no end user really has been involved in testing the features, you also might end up with features the users don’t want or need.

Instead of risking software that does not work and functionality not wanted or needed, you should change to an iterative approach, where for each iteration, you try to get as much feedback as possible about the new features and changes in features done since last time you got feedback.

There is just no way you can think up, upfront, exactly what your end users want and need. You can have a basic idea and work from that, but you need to have a short feedback loop to work on feedback from your users.

Based on the feedback you get, you can inspect and adapt. Maybe you need to go in a completely different direction or maybe you are on track and just need some minor adjustments.

Using a traditional approach, you might not know until your project is done; with an agile approach, you should know very early with plenty of time to make changes.

Building a product that customers don’t want probably wasn’t part of that lofty goal set at the start of the project. You are essentially shifting from “building all these features by the deadline” to instead trying to “build the best possible product by the deadline.”

What If All Features Are Needed?

Sometimes, for regulatory requirements as an example, you can’t just say you have finished the most important features and that’s that. Another important advantage by having short iterations is that you will catch early warning signs that development will progress more slowly than needed for the deadline to be met.

By catching this early, there will most likely still be time to do something about it, like putting additional teams on the development. If you catch these early warning signs, the general rule about putting more people on the problem and how it will only slow you down won’t ring true.

Doing something about the problem when there is still time to do so is one of the great strengths of a short iteration-based approach.

Manage Deadlines with Change in Mind

To a large extent, deadlines are inevitable. Even if a hard deadline hasn’t been set, there usually are expectations of a release date – either internally from management or the ones being impacted by the project, or externally from customers or other stakeholders.

Still, agile promotes a sustainable pace. Short iterations, feedback and a product that works at all stages is the answer. To some, it’s very comforting to manage the development work by looking at all the upfront requirements and managing against those.

This is, of course, a false sense of security – requirements will change while doing the work. We are much better of embracing change and managing deadlines with change in mind.

I welcome your thoughts in the comments below.

How to Create the Minimum Viable Agile at Your Organization

We can probably agree on some of the things that agile is, but then either you or I would say something like: “And I also think agile is …” and offer some additional interpretation of what it means to be agile.

Because of this, a number of different agile methodologies exist. There are also many different values, principles and practices associated with agile.

The concept of a Minimum Viable Agile (MVA), that is, the bare minimum needed to say you are agile, isn’t really new. The Nokia test, first developed by Bas Vodde and later revised by Jeff Sutherland, is an example of this thinking. Many other checklists and assessments on whether or not you are agile exist, so the concept of an MVA seems to be interesting to many.

But why is it beneficial? And how do you create it?

Why the MVA is Beneficial

 The MVA would probably have the most benefit for teams or organizations getting started on the agile journey. Being in an early stage, you can easily get overwhelmed by all the different values, principles and practices of agile.

Defining the MVA could be one of the first steps towards a goal of being agile. The MVA could then be used to map the gaps between how the team or organization operates, and how it should operate to be more agile. Having an explicitly defined MVA will make it clearer which changes should be made and what kind of training is needed.

Having an MVA could also help experienced teams and organizations that have been through these transformations with a baseline of agile to fall back on, should they at any point go the wrong direction concerning their agility. 

How to Create the MVA Creating MVA Based on the Agile Manifesto

A somewhat natural approach towards an MVA would be to follow the Agile Manifesto and use those values and principles as the basis of your MVA. After all, adhering to the values and principles behind the manifesto surely makes a team agile by definition, yes? 

While this could be true, there are some problems related to this approach.

One challenge is that the written values are too vague to translate directly into actions. If you value individuals and interactions, how do you decide if a team adheres to this? The same goes for responding to change—how do you know if a team values this, and to what degree is it followed?

You could probably find some metrics to measure the adherence to the values to some extent, but it is doubtful you will find any specific unambiguous metric to capture this.

It would be great if the principles of the manifesto provided context-specific guidelines for implementing practices based on the values, but the manifesto doesn’t directly prescribe any practices.

What seems like a downfall of the manifesto is actually one of its stronger points. The power of the manifesto lies in its open to interpretation, which leads to agile being more of a mindset than a set of practices.

Therefore, an MVA directly based on the manifesto might prove to be difficult. Also, the manifesto in itself is meant as a living agile document, in that we should always be looking for better ways to make software—not limited to the content of the manifesto as it was written 15 years ago.

So somehow your MVA must reflect this as well.

Creating MVA Based on Existing Agile Practices

Another approach towards creating an MVA for your organization could be to look at all the different agile methodologies and actionable practices from these.

All the methodologies have a slightly different implementation of the core values from the manifesto, so whether your approach is based on Scrum, XP, a Scrum/XP hybrid or a Kanban approach to software development, the idea is to pick just the minimum of practices that makes you agile and call that your MVA.

The challenge is, as mentioned before, that agile looks different to different people. Because of this, there isn’t just one agile methodology.

There are different methodologies with some overlapping practices, but since the creators have slightly different interpretations of what agile is, they also have some non-overlapping practices. As an example, neither Scrum nor Kanban prescribes any of the technical practices from XP. However, often a lot of these are implied when using both Scrum and Kanban.

If you look at the results of the latest State of Agile survey, technical practices like refactoring, pair programming, TDD and collective code ownership are among the least used agile practices. Non-technical practices like the daily standup, prioritized backlogs, short iterations and retrospectives are among the most used practices.

With only 1 percent of respondents saying their agile implementation failed, the problem then becomes which practices to choose as our MVA, given that agile implementations seems to succeed even without technical practices like collective code ownership, TDD, refactoring and pair programming.

My MVA is Different Than Your MVA

The fact is, all teams have different preferences, and the context in which various teams work are not the same. So maybe a generic MVA that we all would agree on isn’t really feasible. A custom MVA for individual teams or organizations that is periodically revised or improved is probably more realistic.

Personally, I don’t think it’s important if there is a single, generic MVA, as long as the teams or organizations are aligned and have a shared and evolving understanding of their own MVA. As long as value delivery is maximized, it shouldn’t matter either.

Do you have an MVA? Share with me in the comments below.