Agile Transition Strategy

In May 2015, I attended Jeff Sutherland’s “Getting to Done” presentation at the DC Scrum Users Group meetup. During his presentation, two things really grabbed my attention.

The first was the Standish Group’s 2011 CHAOS Report, which revealed the percentage of successful, challenged and failed projects using either waterfall or agile methodologies. The second was Sutherland’s statement that “as larger companies adopt Scrum, the percentage of successful agile projects will drop.”  

For the purposes of their report, the Standish Group defined project success as being delivered on time, staying on budget, and reaching completion with all planned features intact. In their 2015 CHAOS Report, they published their findings on the state of waterfall and agile projects that were conducted from FY2011 through FY2015. The results of that report are shown in the table below.

Overall, successful agile projects only dropped by 3 percent, while challenged projects increased by a corresponding 3 percent. However, the more startling statistics begin to become apparent when looking at the success and failure rates of small projects versus those of large projects. 

Small agile projects were approximately three times as successful as large projects, while the failure rate of large agile projects was almost six times greater than that of small agile projects.

In light of this data, the question remains -- why is this happening?

My thoughts are (1) large organizations are feeling the pressure to adopt agile methodologies and do it quickly for fear of being left behind by their competition, (2) large organizations tend to underestimate the level of commitment and effort it takes to successfully transition to an agile environment and (3) they fail to realize that a successful transition is not going to happen overnight.

So, if small agile projects are three times more successful than large agile projects, why not incorporate the advantages of small projects into your organization’s agile transition strategy? Why not transition to an agile environment using a series of small transitions and rolling wave planning?

The advantages of doing so include not taking on the entire organization all at once, spreading out the cost over a longer period and having the freedom to make initial mistakes on a smaller scale with little to no large-scale repercussions. And, as you learn more, each subsequent transition will naturally progress more smoothly than the one before it.

When planning the transition series, consider the composition of your organization’s population. Every organization has three major profile types within its population. 

Those three types are:

Early adopters: These are the kindred spirits who are most receptive to moving forward with new and innovative methods. The silent majority: The mainstream folks who need to see solid evidence of success before embracing a new way of working. The Resistance: Those who are decidedly in favor of the status quo and are neither interested in nor comfortable with change. Their favorite quote is likely to be, “But we’ve always done it this way!”

Execute your strategy in the same order, starting with the early adopters. As you execute your transition, make sure to capture pre- and post-transition metrics as well as the user experience for each project. Then, make sure each project success is widely publicized and that the people who worked on those projects are recognized. 

Repeat this process for each profile type. This will give you the opportunity to build your case for transitioning to an agile environment while simultaneously fostering ground swell.

Using a transition strategy that incorporates this approach lets the organization publicize the fact that they are successfully transitioning to an agile environment, while doing so in a manner that will allow both the organization and its people to truly reap the benefits of a real agile environment rather than an environment that is “agile in name only.”

Mixing Roles in a Scrum Team

One of the powerful advantages of Scrum is having two different types of responsibilities: the shared responsibility for the final product, and the individual responsibility based on each team member’s role.

Responsibility for the product is shared by the whole team: the product owner, scrum master and development team are all collectively responsible for the development and delivery of a working product at the end of each sprint. On the other hand, each one of those team members is also individually responsible for a specific part of the product.

While the product owner is responsible for gathering requirements, shaping the product vision and prioritizing the “What, Why and When,” the development team is responsible for devising ways to  provide the needed features, as well as determining how much time and effort is needed to fulfill the requirements of each user story.

The Scrum Master, by supporting the team and driving them to achieve better results, acts as the catalyst of the sprint.

Despite this separation of roles in a Scrum team, sometimes management thinks that it makes sense for a single team member to take on multiple roles.

I’ve heard about teams where a developer acts as Scrum Master, as well as teams where the Scrum Master role is rotated among the development team members. My view on this approach is that it creates an unhealthy structure due to the conflicts of interests present within each role.

I would find it strange for a developer who is supposed to work on user stories provided by the product owner to simultaneously coach the product owner on how to write and prioritize user stories.

This type of team structure also fails to deepen the development team’s confidence or trust in the product owner to decide what features are needed or make proper decisions.

One other unhealthy situation occurs when the line manager of the team was also a developer who was actively participating in the development. The lack of a boundary between these roles can cause various different problems.

The development team wouldn’t be eager to challenge their “colleague’s” technical proposals, since he or she  is a member of the same team. Sometimes the developer-manager would overrule the product owner, since he or she was the product owner’s manager as well. 

In some situations, user stories might get injected as a result of urgent requirements from management. For example, a user story to show a report needed by the management might get injected in a sprint hindering the delivery of another user story needed by the customers.

A different type of structure, which can be frequently found in startups, involves a developer who is also the product owner. This structure would succeed only if the developer managed to overrule their inner geek in favor of the business needs of the product.

When the founder is not able to differentiate between his or her role as a developer and his or her role as a product owner, the success of the startup can be jeopardized. The few startups that do succeed are able to do so because of this key factor.

In normal cases, I would prefer that the roles in a Scrum team remain separated, as they should be, in order to enable each team member to achieve what is expected from his or her particular role.

Effectively creating a healthy environment in which a team can work properly is critical to the team’s success, and thus should be a top priority for management.

Have you ever worked in a team with mixed roles? I would like to hear about your experiences and thoughts in the comments section below.

3 Reasons You Need to Seek Feedback in Your Agile Process


When it comes to agile teams, far too many of us get trapped in the habit of working independently without a high level of external interaction ‒ this is especially true for teams working on software or web development projects.

While it’s understandable that working with others outside of your immediate sphere can initially seem stressful and overwhelming, investing a little time in clarifying details can go a long way towards cutting the number of iterations in your feature development cycle.

After all, the Manifesto for Agile Software Development teaches us that individuals and interactions, as well as customer collaboration, are core values, which should typically be prioritized over processes, tools and contract negotiations.

Additionally, agile methodologies like Extreme Programming make it a point to collect feedback from the customer on a frequent, ongoing basis ‒ but how many teams actually take that feedback to heart?

I’ve seen too many teams erroneously believe that a two-week sprint means blocking out all feedback from the customer, which can prove to be a mistake in the long-run. If you'd like to help your team move faster and collect as much information from the customer as possible, take a look at these three important reasons why your team needs to seek out feedback during your agile process.

1. You Need to Understand How the Customer Interacts with the Features You’re Building

Many agile teams understand that it’s important to collect customer feedback after an iteration is complete, but it can also be useful to collect feedback while you're in the process of building your shippable iteration.

Giving the customer a preview mode or prototype to interact with can teach you a lot about how they plan to use the features you’re building. Sometimes the way the customer interacts with the features you build is markedly different from the way in which they were expected to.

Using an abstract hypothetical, a car customer could ask an agile team to build an ejection seat to prevent death during a car crash, but their core need is more likely to be an airbag. Why? Because an airbag can better address their core requirement ‒ reducing death and injury with an efficient, cost-effective product that can get to market quickly.

While many agile teams understand the importance of collecting true customer requirements based on true user needs, why not do this on a much smaller scale as well? Your customer won’t wait for your two-week sprint to conclude before changing their mind or providing clearer requirements, so why not collect their feedback on a day-to-day basis?

Some folks may argue that all requirements should be collected perfectly up front, but making this assumption would be failing to prepare for the cases where requirements change or become clearer over time ‒ something that happens far more often than many of us want to admit. After all, responding to change is what agile teams are all about, so why block out input instead of seeking it as quickly and regularly as possible?

Sure, we can organize tasks and goals into short-term sprints without adding additional tasks or requirements, but if your requirements aren’t correctly and clearly defined at the outset of your two weeks, you’ll find that not communicating with the stakeholder during the sprint will surely result in an increment that could have better met customer needs.

2. You Need to Understand the Context of the Features You’re Building and the Work You’re Doing

The features you ship don’t exist in a vacuum ‒ real customers are interacting with these features and the results they produce. It’s important to understand how the customer interacts with the features you build on as frequent a basis as possible.

Talk to customers, and talk to them often. Don’t talk to customers solely on an individual level, but collect data on an aggregate level as well. Think about the industry or market you’re serving and its particular requirements.

In some cases, your customers may not even understand their own requirements as clearly as you can. For example, high school students might be the target market for a website or application designed to help them get into better universities, but these customers ‒ high school students ‒ may not even clearly understand the best methods to get into the best universities in the first place.

In other words, you may need to conduct research beyond customer feedback and in turn educate your customers about what they need.

There’s so much context that can help you understand the customer, which goes beyond their feedback ‒ terminology, regulations and laws, best practices and much more. Don’t assume your customers will simply tell you everything you need to know up front ‒ the features you’re working on may need to guide them or provide solutions that they themselves have not yet conceived of. 

3. You Need to Uncover True Requirements Much More Quickly

As I've already alluded to, it’s crucial to reduce the cycle of understanding requirements as much as possible. Idealists will tell you that requirements should be completely understood from the get-go, but this is often an unrealistic goal.

The reality is that requirements change ‒ the customer themselves may realize new requirements, laws and regulations may change, terminology may change and a slew of other changes may occur, all of which can lead to the introduction of different requirements. Ignoring these changes in requirements simply means extending the amount of time spent building towards incorrect requirements, which will ultimately amount to wasted effort on your team's part.

As agile teams, most of us like the concept of a protected sprint, but this shouldn’t blind us to the introduction of real changes in the marketplace or customer needs. The worst thing you can do as an agile team is ignore changing realities and, in doing so, fail to adapt to changing requirements.

What You Can Do About It

Want some actionable ways you can better adapt to changing conditions? Keep in constant contact with your customers and end users.

Do frequent research on the context surrounding your product and users, such as laws and regulations, marketplaces, terminology and any other relevant factors. Shorten feedback loops as much as possible ‒ do not shy away from customers, and force yourself to interact with them and ask as many questions as you can.

Remember, agile is all about responding to change, so staying ignorant to the changes surrounding your work is a fatal mistake. Don’t just respond to change ‒ seek to study and anticipate changes as quickly as you can, and you’ll be able to ensure the iteration you’re working on is heading in the most accurate direction possible.




Personal Change: Unlock Successful Organizational Transformation

Here we are, about month and a half into the new year. According to Gold’s Gym, it’s also the “fitness cliff” - the week most of us will stop going to the gym.

Why is it so hard to keep those resolutions, to make changes stick? After all, there are only three things one needs to know to embark on change:

Where we are (me: a bit over 14 stones) Where we want to be (a stone less) The means we should try to maneuver the territory between #1 and #2 (eat less, exercise more) Old Habits Die Hard

One reason individual change can be so difficult is the power of habits. All of us have created many routines over the years. These behaviors have not only been responsible for our success, but have also helped shape our inner identity. We have been rewarded for certain behaviors, which we then strove to maximize. And we have likely been disincentivized (punished) for our non-compliant behaviors.

Meet Your Inner Reptile

One of the biggest obstacles to modifying our habits is our amygdala. That element of our brain structure gets direct inputs from our senses. It is highly pattern-focused, and processes many of our memories and past experiences.

The amygdala has a direct line to the neural networks that activate both our reward (approach) and threat (avoid) circuitry. It is very, very sensitive to danger and does its computations rapidly, well before we have had a chance to think things through with our much newer (and much slower) brain structures.

That ancient part of our brains helped our ancestors stay alive long enough for us to emerge from the evolutionary tree.

Thank Goodness for a Neocortex

Fortunately, we can work with the adaptive nature of our newer gray matter - our neocortex - to help us make change happen and stick.

Social neuroscientist David Rock has done extensive study into how the neural networks of both our older and newer brain structures impact our behavior in groups. I believe his model offers a key to unlocking successful change at an individual level - which then can cascade to the organization.

Rock’s SCARF model looks at the following five areas of social interaction:

Status – Relative importance Certainty – Ability to predict the future Autonomy – Sense of control over events Relatedness – Sense of safety with others (Are you my friend or my foe?) Fairness – Perception of fair exchanges (Are the rules of the game are clear?)

Being aware of these five domains and their influence on our behavior during periods of change will help each of us to get in touch with what might otherwise remain buried deep in the older recesses of our brains.

This understanding will help us when it comes time to making new kinds of decisions and taking new actions. It will help us manage our emotions and our stress levels when dealing with the uncertainty that accompanies change, when the path forward is unclear.

Gaining control over our emotional reactions to the stress of change and being able to train our neocortex to inhibit our amygdalas will have an added benefit of making us smarter. I’m not kidding here. Studies have shown that when we are in a stressed or threatened state (i.e., amygdala on high alert), there is literally less oxygen and glucose for the neocortex’s cognitive functions.

Unwrapping the SCARF

Let’s explore a couple of elements of this model in the context of a middle manager making individual changes to move from a command and control attitude to an agile mindset.

Our manager has likely attached much internal meaning to the importance of her status as a boss. She may have even responded in the past with aggression should her power be challenged (“We can’t possibly deliver X scope by Y date, boss”): “It’s my way or the highway!”

This is because a threat (perceived or real) to her status activates exactly the same primal neural networks as a threat to her life. And cortisol, the stress hormone, flows fast. That vigilant amygdala processes stimuli well before things reach her conscious awareness.

Well, that now presents a problem, eh? To be successful on the journey of embracing agility, our middle manager has to look at things in a very new way … decisions will need to be distributed to the wisdom of her teams, not addressed by hierarchy. And if using a Scrum framework, the team will not be dictated scope and delivery dates, but will themselves decide how much of a workload to accept in a given iteration.

Fortunately for our manager, there are tools that will help build a bridge to a new way of interacting:

Team Agreements Delegation Matrices Definition of Ready (DoR) Definition of Done (DoD) Enabling Self Learning Teams

Created in a spirit of collaboration with the manager’s teams, these tools can develop an environment of greater certainty, autonomy, and fairness, paving the way for good change - and not just for the manager.

The Power of Iterative Change

But as mentioned above, it will take time for our manager to change her ways, to move out of her habit-realm (See above: Old Habits Die Hard). Her evolution will likely be bumpy as she trains her neocortex to inhibit her amygdala.

In the beginning she will start to catch herself after the fact of an amygdala hijack. (“Damn, I just [gave out an order, provided the ‘right answer’, yelled at the team]…”) During her next stage, she will catch herself in the act (“WTF is wrong with them! typing… getting ready to hit reply all… oh wait…. save draft instead of send.”) Emerging to neocortex domination, she will think about things before she acts. (“Feeling the need to say something that really what’s best? Let me count to five first…”) Arrival: She says and acts in a new way (or in some cases does not act) without forcing herself to think about it.

All along this path, people will value our middle manager differently. Not because of the implied power of her position but because she is changing in a way that brings out the best in others. Voilà: Status reward.

And here’s a really cool thing: People think about themselves using the same neural networks they use for thinking about others. As our ex-command and control manager begins to make breakthroughs in her own growth, doing better than last time, her own internal reward circuitry will be activated!

Unlocking Organizational Transformation

Sure, it can be hard to keep those New Year’s resolutions. However, the good news is that with conscious effort (and the support of a good coach), we can make changes that stick.

Along the journey, we will need to pace ourselves, taking time and making space to:

Pause and reflect Accept and learn from failures (don’t sweat ‘em, just don’t stop trying) Celebrate accomplishments, big and small Expect the unexpected

And since all organizations are composed of individuals, this collective pursuit of individual change will lead to greater things.  

As we make breakthroughs in our own growth, we will likely become more aware of potential changes to organizational systems – compensation, flexible work arrangements, extrinsic motivations, information flow, training, on boarding and a vast range of other structures – that can have a huge impact the SCARF domains of our environment.

All of this is the master key to unlocking successful transformation at the scale of our organizations.

The Role of a Product Owner (Part 3): Anti-Patterns

Part one of this series examined the responsibilities and characteristics of a product owner; part two looked at their daily activities during a sprint. This third post focuses upon common anti-patterns seen with the product owner role.

Here are my “dirty-dozen” product owner anti-patterns:

1. No Single Product Owner

Each Scrum team must have a single product owner. Multiple stakeholders are acceptable and usual, but one person must be identified and empowered in the role of product owner for the team.

Solution: Identify a single product owner for each team.

2. Inaccessible Product Owner

The product owner must be available to the team to answer questions whenever required so as not to reduce capability and lower morale.

Solution: The product owner must be present to support the team during development - aim for at least 50 percent availability.

3. Proxy Product Owner

When the real product owner is unavailable, and a proxy is appointed, then it is critical that they are fully empowered within the role. Proxy product ownership often leads to delayed decision making, conflicts in direction and an overall lack of trust within the team.

Solution: Engage the real product owner or fully empower a proxy. Additionally consider employing specialists to provide extra support.

4. Role Confusion

There are only three roles within a Scrum team - product owner, Scrum Master and developer. The Scrum Guide specifies each team role, following this guidance helps to avoid confusion and potential corruption of the framework. Additionally, the product owner should never be double-hatted as the Scrum Master.

Solution: The product owner should perform that and only that role. Also, note that the product owner is part of the Scrum Team and not separate to it.

5. Lack of Product Focus

The product owner’s focus must be on developing a successful product. When the role is confused as a managerial role it can attract political appointments and results in sub-optimal performance.

Solution: “The product owner is responsible for maximising the value of the product and the work of the development team” - The Scrum Guide 2016.

6. Inadequate Product Backlog Management

The product owner is responsible for creating and managing the product backlog. By evolving the product backlog during development, the product owner maximises return on investment and improves customer outcomes.

Solution: The product owner must maintain the product backlog so that the work is visible, transparent and ordered.

7. Poor Feature Slicing

Product Backlog Items should consist of vertical slices of end-to-end functionality. Solutions are developed and delivered incrementally from skeletons, prototypes, minimum viable products and minimum marketable products to fully featured products.

Solution: Create work based on the end-to-end value to maximise feedback and reduce risk.

8. Lack of Vision

The product owner creates and communicates the vision for the product based upon customer domain knowledge and an understanding of the development life-cycle.

Solution: Create a clear vision and communicate it to everyone.

9. Faster, Faster

Pursuing the speed of delivery over customer outcomes does not lead to long-term product success. Although shorter lead times (concept-to-cash) is great for feedback cycles, sometimes faster is just faster.

Solution: Focus on addressing customer’s needs with high-quality solutions, iteratively and incrementally.

10. Failure to Trust

Product owners must demonstrate trust in the development team in their words and interactions. Trust prevents poor practice such as:

Stretch Goals- Product owners identify extra work “in case the team finish early.” If the development team completes the planned sprint work early, they will ask the product owner what they would them to work upon next. Development Interference- Micro-managing teams plus tracking and chasing each task performed. Self-organising teams require leadership and not management. Estimates as Deadlines – The development team forecast the work to be completed within a sprint. This estimate can change and the product owner must take this into account.

Solution: Trust and support the development team to deliver.

11. Absent Governance

Scrum is not the absence of discipline; governance is still essential to maximise value and minimise risk. The correct outcome-based metrics are required in addition to stakeholder and risk management. Applied correctly, agile projects are lower-risk and more transparent to everyone involved.

Solution: Provide appropriate light-touch governance throughout development.

And we are done. “That was only eleven anti-patterns and not a dozen as you claimed” I hear you cry, well that is because we are agile and always finish early (wink, wink).

Hopefully you recognise some of these patterns and can avoid some of the others.

You have to learn from the mistakes of others; you won't live long enough to make them all yourself.”

- Eleanor Roosevelt (quote attribution is actually unclear, though Mrs. Roosevelt is the best match)

In the final post of this product owner series, I will focus upon the pragmatic considerations of the role.

What do you think? Please let me know in the comments below.

Agile Examinations

Imagine walking into a school examination hall and opening up your exam paper to find a single question. As you complete your answer, a mark appears and the next question is revealed. However, this time you have some all-important feedback from your previous question.

Now I don't know whether the examination’s outcome would improve, however it does provide options:

1. If you got the question right, the best course of action would be to continue what you are doing.

2. If you got it wrong you can:

a) Chose to adapt your next answer or

b) Decide to get up, leave and do something more valuable instead.

No, this isn't an excerpt from J.K. Rowling’s next book. Welcome to the world of agile education.

From an early age, we are conditioned to get all the answers right the first time and take large upfront tests of our knowledge. This mindset can also be seen in our working lives, where there is a belief that if we research and study the customer hard enough, we can determine exactly what they need through analysis and assumption.

In his book: “Kanban from the Inside” Mike Burrows describes the need to shift mentally from taking orders and fulfilling requests to discovering and meeting people’s needs. This is reinforced in the opening line of the Agile Manifesto, "We are uncovering better ways..."

So how does this relate to examinations exactly? Think back to your most recent exam; it may have been a CSM or PSM you were sitting. You probably attended a course and then spent many hours reading and storing away knowledge that may or may not be tested in your exam session.

Now imagine you were instead assessed on the quality of the hypothesis you construct, how you might go about testing it or what you have put in place to accommodate the possibility your hypothesis may be invalid. This calls upon an entirely different set of skills and thinking patterns.

A few years ago, I had the good fortune to spend time with the former NFL player Eric Boles, who, since leaving the world of American football, spends time with teams and individuals, helping them identify their limiting beliefs.

One of the insights he shared which has stuck with me is, "What got you where you are today, will not get you where you want to go tomorrow."

Now I have no doubt this quote is attributed to someone else and please let me know in the comments if you've heard it before. However, he delivered it with such impact that it placed in my mind the image of a trapeze artist, swinging gracefully through the air, grabbing the next trapeze yet refusing to let go of the previous one.

The result is they become physically stretched by these two opposing forces and lose significant momentum.

This is what can happen to us and our teams when we are not ready to let go of that learned behavior of getting it right first time. Eric stressed that the act of letting go can feel very daunting at first, yet it is something that, practiced regularly, can start to replace the need to know all the answers.

So how might this look in practice? First, we need to free ourselves from the perceived need to know the right answer and instead focus on choosing the right experiment.

Invariably this first experiment will be big and daunting, so break it down to the smallest possible question (or hypothesis) that creates a feedback loop.

Once established, customer feedback loops are like an uncertainty vacuum, removing doubt and replacing it with the confidence that you are meeting a real need. They also work in two directions: As you discover more about a customer’s needs you provide more of what they seek, then the relationship grows and the customer shares more.

So next time you get a feeling in your stomach that what you're developing is not what the customer needs, listen to your intuition and shift your focus to the question: "What is the smallest, safest experiment I could conduct to gain feedback?”

You may not get it right first time, but that's the point. Examinations measure knowledge at a point in time, whereas learning = continuous growth!

What do you think? Let me know in the comments below. 

Agile Lawn Mowing Part 1: A Story of Acceptance

I love mowing the lawn. Compared to the day job, yard work shows an instant transformation as a result of your efforts. My dad is now 86 and struggling with his health, so I wanted to help him out. His mower is a big, heavy, petrol-driven beast, so whilst it does a good job, it’s heavy to manoeuvre, and I thought he’d be glad of the offer.

So I mowed the lawn, emptied the grass box, trimmed the edges and felt pleased with my efforts. But dad wasn’t. We hadn’t discussed “acceptance criteria” before I started. I’d assumed my own acceptance criteria:

Lawn must have nice stripes! Grass must be no shorter than 2 centimeters, or else the grass will die in the sunshine.

Dad had an extra criterion–must not drop cuttings!

As I’d let the box get too full, there were places with a fine trail of cuttings which had leaked out! I could rake the whole lawn or just mow it all again. If I raked it, there was no guarantee he’d be happy, and there was a risk that the stripes would lose their edge.

I chose to mow the whole lawn again, effectively doubling the effort and, in agile terms, halving my velocity.

Conscious Acceptance versus Subconscious Acceptance

Maybe you are already shaking your head and saying, “Ah yes, you should have agreed to the acceptance criteria before you started.”

Well, yes, and that works well for criteria which are conscious. However, it can be difficult to articulate exactly what you want or what you consider acceptable until you see what is not acceptable to you. That is when the subconscious criteria emerge.

For example, on a recent project, we were designing and building a mobile phone app with a feature to capture a photo into a scrapbook. Conscious acceptance criteria covered the size of the image, choosing a picture from the library or using the camera to take a new shot. But it was only when a basic implementation was done in an early sprint that subconscious became conscious and the product owner started to talk about cropping and editing the image as well and handling landscape and portrait differently.

This is where, in my experience, an agile approach to software delivery really pays dividends compared to waterfall delivery methods. On a waterfall style project, I would hear conversations like “That wasn’t in the requirements, so that’s a change request,” followed by “it is obvious that it should be included–that is standard processing for photo capture!” 

In an agile project, sharing as soon as it’s reasonable to share means that when gaps arise, they can be discussed as future backlog items and prioritised in the context of the whole project. In our case, the mobile app was for a health data service and the photo capture was a secondary feature compared to many of the other items on the backlog, and so the product owner consciously chose implementing security around handling personal health data over complex photo editing features.

Unlike mowing a lawn or taking a photo with a phone, many software projects are implementing something that has never been made before, something that neither the product owner nor the team can fully imagine as they are discussing acceptance criteria.  Which brings me back to rapport and empathy and a good relationship between the team and the product owner for delivering the common vision.

Emotional Acceptance

In terms of keeping the product owner involved, I’d sent Dad inside to sit down and have a cup of tea. If he’d been watching me, he would most likely have commented after the first time I dropped cuttings on the lawn, making his subconscious conscious. I’d have been able to adapt sooner and reduce the rework.

However, Dad might not let me mow the lawn again. His experience was that we don’t share the same standards and, although the job got done exactly to his satisfaction in the end, how he felt about the job may still influence him in the future.

For me, acceptance criteria are more than a checklist. They reflect what is important to that person in a wider context. A product owner leaves clues about what is acceptable, and it’s our job as analysts and designers to constantly pick up on them if we want to keep a good relationship and deliver a good project.

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.