Individuals and interactions over processes and tools

Agile manifesto

Agile is all about mindset and culture yet still in many transitions applying this primary value is overlooked for the agile transition itself. In general, a transition strategy, including organisational changes and process definitions, is communicated after it has been decided on somewhere in the organisation. Now if we accept an agile transition is a project and we look at the following agile principle;

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Principles behind the Agile Manifesto

It isn’t that hard to understand that we missed a step. Unfortunately it’s a crucial step, it’s the difference between doing Agile and becoming Agile.
Lucky for us, that step was already defined long before the Agile Manifesto, it is the Community of Practice.

The Community of Practice

Communities of practice provide a model for connecting educators in the spirit of learning, knowledge sharing, and collaboration…

Cambridge, Kaplan & Suter

What is a community of practice?

• A community of practice (CoP) is a group of people who share a common concern, a set of problems, or an interest in a topic and who come together to fulfill both individual and group goals.
• Communities of practice often focus on sharing best practices and creating new knowledge to advance a domain of professional practice. Interaction on an ongoing basis is an important part of this.
• Many communities of practice rely on face-to-face meetings as well as web-based collaborative environments to communicate, connect and conduct community activities.

Why communities of practice are important

According to Wenger (1998), communities of practice provide five critical functions. They:

• Educate by collecting and sharing information related to questions and issues of practice
• Support by organizing interactions and collaboration among members
• Cultivate by assisting groups to start and sustain their learning
• Encourage by promoting the work of members through discussion and sharing
• Integrate by encouraging members to use their new knowledge for real change in their own work.

Communities of practice are important as a professional learning strategy, because they have the potential to:

• Connect people who might not otherwise have the opportunity to interact, either as frequently or at all.
• Provide a shared context for people to communicate and share information, stories and personal experiences in a way that builds understanding and insight.
• Enable dialogue between people who come together to explore new possibilities, solve challenging problems, and create new, mutually beneficial opportunities.
• Stimulate learning by serving as a vehicle for authentic communication, mentoring, coaching, and self-reflection.
• Capture and share existing knowledge to help people improve their practice by providing a forum to identify solutions to common problems and a process to collect and evaluate best practices.
• Introduce collaborative processes to groups and organizations to encourage the free flow of ideas and exchange of information.
• Help people organize around purposeful actions that develop tangible results.
• Generate new knowledge to help people transform their practice to accommodate changes in needs and technologies. (Adapted from Cambridge, Kaplan & Suter)

The professional learning needs of educators are changing. Communities of practice offer a robust strategy for professional learning. Here is why:

• Complex problems require more implicit knowledge, which cannot be codified.
• Implicit knowledge can only be shared through conversations and observation.
• Collaborative and distributed work is becoming the norm.
• Knowledge sharing and narration of work make implicit knowledge more visible.
• New ideas come from diverse networks, often from outside the organization.
• Learning is part of work, not separate from it. Communities of practice enable the integration of work and learning.

The value of communities of practice is in the depth of participants’ reflection and inquiry, and how they put co-created knowledge to action.

Success factors

Wenger has identified a number of factors that contribute to the success (and failure) of communities of practices. His ‘top three’ factors include:

• Identification: Communities of practice thrive on social energy, which both derives from and creates identification. Passion for the domain is key. This makes the clear identification of the domain a critical success factor.
• Leadership: A key success factor is the dedication and skill of people who take the initiative to nurture the community. Many communities fail, not because members have lost interest, but simply because nobody has the energy and time to take care of logistics and hold the space for the inquiry.
• Time: Time is a challenge for most communities, whose members have to handle competing priorities. Theoretically, time should not be an issue if the interest is there, but practically it remains a constant challenge. Because time is at such a premium, a key principle of community cultivation is to ensure “high value for time” for all those who invest themselves.

The research describes a number of factors for success including:

• Identifying a domain that energizes a core group
• Recruiting a skillful and reputable facilitator
• Tapping into the expertise of local and international experts
• Addressing details of practice
• Establishing the right rhythm and mix of activities
• Having visible support of organizational leaders, but without micro-management
• Accessing adequate resources in order to reduce barriers to participation.

The research also identifies these additional factors that contribute to a successful community of practice:

• self-governance
• a sense of ownership
• the level of trust
• recognition for contributions
• high expectations for value creation
• organizational support
• connection to a broader field
• interactions with other communities

In conclusion

Looking at the elements of the Community of Practice and how they match the mindset of the core agile values I hope this can help you leading successful transformations.

If you would like to know more or need help, feel free to reach out.

Working in the development industry and experiencing changes in the way of working first hand, led me to writing this article. Regardless of paradigms, the goal is to develop working solutions for internal/external customers in a timely cost efficient manner. This perspective is especially important for scrum masters to understand their role. 

In many teachings the focus of the role of a scrum master is primarily defined as guiding the team(s) through the rituals of the chosen framework in a rigid process focused manner. This narrow focus is more often than not becoming its own impediment.

Being adaptive and agile means being able to change decisions all through the pipeline by iterating back and forth between the people who have responsibility for delivery and those who are responsible for understanding the marketplace. If we want business agility we need innovations of every size to flow through the organisation’s delivery pipeline without being blocked by gates, bad interaction or poor project management techniques. The paradigms and frameworks are there to serve organisations achieving the mindset and having a blueprint to deliver value.

From this we can derive the real role of the scrum master. The scrum master is the facilitator, responsible for managing the flow. The scrum master should focus on culture and interaction as well as a few guidelines. The scrum master uses the framework and tools to power an intense level of social interaction and a decisions flow from good interaction at work. 

The scrum master is the flow master. The scrum master evaluates where he can be of service to make sure we have a predictable continuous flow in the delivery of working solutions. This adheres completely to the principles of original agile manifesto:

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

Organisations need to recognise this in order for any agile transformation to succeed.

If you would like to know more about flow or need help in exercises to improve flow, feel free to reach out.

After successfully completing the course at Digital Delta, I can conclude it is almost the same as the role of the scrum master. The only difference is the domain specific knowledge the architect shares (not dictates) with the teams but:

Emergent Design

Ideally, Agile Development Teams are supposed to have the mandate to decide how and what to improve on the architecture. As features develop by order of highest demand, so each team should grow the architecture needed to support them. This is paraphrased under the concept of ‘emergent design’, and it follows from Agile principle number 11.

Complexity brings risk

That is fine for the low complexity of a start-up. In a scaled environment however, with many teams developing products at the same time, whose products are getting more and more complex, with several layers of communication within and externally, extracting data from many different sources… emergent design is a recipe for instability at the structural level. It isn’t enough to just ‘KISS’, because

“For every complex problem there is an answer that is clear, simple and wrong” Henry Mencken

So how do we define architecture in a complex context? To simplify isn’t even always a possibility, the same way as downscaling isn’t always the right thing to do. Instead, we have to work with complexity and try to organize as much as possible. One possible answer for that is the Intentional Architecture as designed and executed by the architects at the System, Solution and Enterprise levels.

An intentional frame for emergent details

Whether you’re a System, a Solution or an Enterprise Architect in a Lean-Agile enterprise, you are in charge of providing a strategy and vision to improve the architecture incrementally, leaving enough room for a coordinated emergent design effort brought on by the development teams. You provide the powerful and coordinated base for Agile teams to keep focusing on delivering value to end customers. It’s up to you to build the right amount of architecture that will enable this value to be implemented and potentially delivered.

You have a responsibility to help teams coordinate, define and share information at the appropriate levels; to understand the underlying purpose and also to be influential enough to direct the fitting amount of funding to the technical aspects and evolutions, to ensure it will get done.

The key is in the balancing act

Balancing sensibly between intentional architecture and emergent design, supported by techniques such as Model-Based Systems Engineering and Set-Based design.

If you would like to know more or need help, feel free to reach out.

One of the principles behind the Agile Manifesto is using an efficient and effective method of conveying information to and within a development team (the best way being a face-to-face conversation). The following points reveal why email is ineffective for productivity as well as a big source of frustration.

Email overload

The average worker will receive 122 of those emails each day, of which less than half will contain relevant information. When people are bombarded with all of this superfluous information, they simply bulk delete or skim through, missing important information that is buried. The sheer number of messages we receive leads to the most important ones getting lost, deleted, or forgotten. In addition, people are easily frustrated when their workload becomes overwhelming. Just one email can prove highly distracting. Just consider all of the newsletters and blogs to which you’ve subscribed. Reading through a single one can consume an inordinate amount of time, distracting you from the task at hand. In fact, studies show that after reading an email it can take up to twenty-five minutes to refocus on the work you were originally doing.

Wasted Time

The McKinsey Global Institute found that the average employee spends 13 hours a week checking, reading and responding to emails— eating up 28% of the work week. With less than half of emails deserving attention and many going unread, this is a lot of wasted time. On top of this, simply getting back to work after answering an email takes an average of 64 seconds. This enormously decreases productivity.

Not Made for Collaboration

Email was not designed to be a collaboration tool. From managing projects to troubleshooting a problem, neverending email threads become inefficient, confusing, and bad for productivity. With many collaboration and project management products available, email should never be the place you turn in order to stay on top of tasks and projects.

No Accountability

With email, there is little accountability. There no way of knowing if people have read an important update and anything can be chalked up to, “Oh, I didn’t get that email.”

Emails don’t support engagement

Email lacks the easy user experience of social commenting and as soon as more people join a conversation it becomes confusing (Email hardly ever stays on topic).

Email does not facilitate continuous feedback

People need feedback. Consistently. Top-down (as well as peer-to-peer) communication is essential for keeping this loop running effectively. But giving regular feedback via email takes a lot of work.

In comparison, modern communication channels like document solutions with embedded commenting systems encourage interactive conversations between peers, while push messages allow to give better feedback in less time. Plus it can be targeted and sent “on the go.”

Ineffective Content Repository

We’ve established why email is ineffective for collaboration but it is also a poor repository for company knowledge. Searching your inbox is always a headache. You rack your brain for a keyword or who sent the email or worse what date it was received. There is simply no way to remember all of that detail when your inbox is clogged up with hundreds of emails.

Secondly Email content is scattered and has no guardian. When people leave or get assigned into another position parts of the truth get lost.

Conclusion

Based on the above Email is ineffective for Agile communication. For an agile drive to succeed, it’s crucial to take a strategic approach using a solution that effectively connects teams in real time so they can collaborate, get answers and share information in an efficient and effective manner. Even more, we must ensure communication is unlocked to all levels of the organisation.

Note

Personally I favour the Atlassian suite to structure project communication but you can use any collaboration platform that meets your needs.