Tag Archives: Software Development

01.01.26
by

Bridging Learning and Evaluation: Using OKRs to Empower Students in Collaborative and Individual Learning

In recent years, educational innovation has been inspired by practices designed initially for industry, from Agile to the most recent InnerSource. Educators are increasingly reimagining how students can learn through collaboration, iteration, and transparency. However, as universities experiment with such open, collaborative models, the question of how to fairly evaluate both individual and collective contributions becomes more complex.

One powerful yet underexplored approach to evaluation in higher education is the adoption of OKRs (Objectives and Key Results), a goal-setting and performance framework widely used in industry to align teams, measure progress, and drive accountability. When thoughtfully adapted to academia, OKRs can complement methods and practices like Agile and InnerSource, enabling student-centred, transparent, and continuous evaluation across disciplines.

Why OKRs Make Sense in Education

OKRs encourage alignment between individual goals, team objectives, and institutional learning outcomes. In a traditional educational model, evaluation is often backwards-looking — grades reflect outcomes rather than growth. OKRs, in contrast, are forward-looking and iterative, focusing on measurable progress and learning impact.

Incorporating OKRs into university courses, particularly those leveraging InnerSource practices or project-based learning, offers several key advantages:

  1. Clarity and Purpose.
  2. OKRs help students understand why they are doing something, not just what they are doing. This builds intrinsic motivation and a sense of ownership over learning outcomes.
  3. Continuous Feedback Loop.
  4. Like Agile sprints or InnerSource peer reviews, OKRs emphasise iteration. Regular check-ins (e.g., every 2–3 weeks) enable professors and teams to realign objectives and assess progress dynamically rather than relying on static midterms or finals.
  5. Balance Between Autonomy and Accountability.
  6. Students define their own objectives within the scope of the course’s goals. Professors act as mentors, guiding the alignment between personal learning trajectories and team deliverables. This balance promotes self-management and collaboration — two critical professional competencies.
  7. Measurable Soft Skills Development.
  8. Traditional grading struggles to capture growth in communication, teamwork, or leadership. OKRs, especially when integrated into InnerSource-style collaborative environments, make these “soft” skills visible and measurable through concrete key results (e.g., “Lead two peer review sessions and provide feedback on at least three pull requests”).

Implementing OKRs in Academic Contexts

1. Individual OKRs: Driving Personal Growth

Each student defines personal learning objectives aligned with the course’s overall goals. For instance, in a Software Engineering course using InnerSource repositories:

  • Objective: Improve collaborative coding and code review skills.
  • Key Results:
    • Submit at least three pull requests reviewed and approved by peers.
    • Lead one peer review discussion with constructive feedback.
    • Resolve at least two issues raised by teammates.

These key results can be automatically tracked through version control analytics or peer-review metrics, creating transparent, data-driven evidence of contribution.

2. Team or Group OKRs: Structuring Collaborative Work

In disciplines involving projects (Engineering, Design, Business, etc.), teams can define shared OKRs that reflect both product outcomes and process maturity.

  • Objective: Deliver a functional prototype that meets stakeholder requirements.
  • Key Results:
    • Complete all core features by Sprint 4.
    • Conduct usability testing with at least 10 participants.
    • Document and present results to the class and external mentors.

Here, the emphasis shifts from individual grading to collective accountability, mirroring professional project environments. Each team’s OKRs can be reviewed in structured checkpoints, ensuring transparency and consistent evaluation standards.

3. Cross-Disciplinary OKRs: Enabling Interconnected Learning

Just as InnerSource envisions a unified educational “mega-project,” OKRs can operate at higher levels linking objectives across multiple courses or faculties. For instance, a capstone project combining Computer Science, Business, and Design could establish overarching OKRs that align individual contributions with interdisciplinary outcomes.

  • Objective: Create a market-ready digital product prototype integrating technical, business, and design perspectives.
  • Key Results:
    • Deploy a functional MVP using InnerSource collaboration.
    • Develop a viable business model validated through market testing.
    • Present interdisciplinary findings at the university’s innovation fair.

Such alignment fosters systems thinking and helps students appreciate how diverse disciplines contribute to holistic innovation.

Evaluating Students with OKRs

Evaluation using OKRs shifts from grading what students deliver to assessing how they progress toward meaningful objectives. The approach combines quantitative and qualitative metrics:

  • Quantitative:
    • Repository activity (commits, reviews, issues resolved).
    • Objective completion rates.
    • Peer review participation.
  • Qualitative:
    • Reflection reports discussing learning outcomes.
    • Peer and mentor feedback on collaboration and leadership.
    • Demonstrated alignment with course-level goals.
    • We can evaluate communication, collaboration, teamwork, and organisational skills.

Professors can evaluate students in three complementary dimensions:

  1. Individual learning growth (via personal OKRs).
  2. Team performance and contribution (via group OKRs).
  3. Interdisciplinary integration (for cross-course projects).

This approach enables a 360-degree evaluation system—one that values both autonomy and collaboration, as well as process and outcomes.

Challenges and Considerations

Adapting OKRs for education comes with challenges similar to implementing InnerSource:

  • Training and Calibration: Students and professors need orientation on setting realistic, measurable OKRs.
  • Consistency: Overly vague or ambitious OKRs may lead to frustration or uneven evaluation.
  • Tooling: Integrating OKR tracking with existing platforms (LMS, GitHub, or Project Management tools) ensures data consistency.
  • Equity: Clear guidelines are needed to balance recognition of individual effort within team outcomes.

However, these challenges can be mitigated through structured onboarding, template OKRs, and regular coaching sessions, which echo the phased approach already proven effective in InnerSource adoption.

The Synergy Between InnerSource and OKRs

While InnerSource provides the collaborative infrastructure, OKRs provide the evaluative compass. Together, they create a powerful feedback loop:

InnerSource FocusOKR Contribution
Collaborative learning and contributionClear objectives and measurable results
Peer review and mentorshipStructured accountability and recognition
Iterative improvement cyclesRegular goal-setting and progress check-ins
Transparent repositoriesTransparent evaluation metrics

This synergy bridges the gap between learning and assessment, transforming evaluation into an ongoing, participatory process rather than a one-time event.

My Thoughts: From Evaluation to Empowerment

The adoption of OKRs in higher education represents a shift from grading performance to cultivating purpose-driven learning. When integrated with InnerSource-inspired collaboration, OKRs can transform large-scale courses into dynamic ecosystems of continuous growth, peer learning, and innovation.

Students are no longer passive recipients of assessment but active co-creators of their educational journey, capable of setting goals, measuring impact, and reflecting on progress, skills essential for thriving in the modern, agile, and interdisciplinary workplace.

As universities navigate the evolving landscape of education, combining InnerSource practices with OKR-based evaluation offers a promising pathway toward scalable, fair, and future-ready learning.

Acknowledgements: I would like to sincerely thank Sara Santos for her careful review and insightful feedback, which helped refine and strengthen this work.

#OKRs #InnerSource #CollaborativeLearning #HigherEducation #AgileEducation #SoftSkills #EvaluationInnovation

08.18.25
by

Scaling Collaborative Learning: Harnessing the Power of InnerSource for Courses with 250+ Students

After sharing a short article titled “Unlocking Innovation with InnerSource: Why Organisations Should Embrace” and a paper I co-authored that was presented at the HICSS conference titled “Agile and InnerSource: A Match made in Heaven and in Hell!“, my friend Nuno Seixas challenged me to share my thoughts on scaling collaborative learning with InnerSource in courses with over 250 students. I gladly accepted this challenge, and here are my insights.

Additionally, before starting, I would like to thank my colleagues Clare Dillon and Daniel Izquierdo Cortázar for their helpful review and feedback.

Scaling collaborative learning in large educational environments presents unique challenges, especially in courses with many students [1]. The InnerSource practices, inspired by open-source software methods, offer an effective strategy to address these challenges. InnerSource applies open-source principles such as transparent collaboration, shared development, and community engagement within an organisation or closed group. Based on my discussions with several professors and students, this approach is already being partially implemented in specific courses, such as Software Engineering, with promising outcomes.

In the current social media-driven world, there are noticeable gaps in communication and teamwork skills among students [2]. InnerSource can significantly narrow this gap by fostering a collaborative learning environment where students develop their soft skills, particularly in communication, teamwork, and problem-solving. These skills are highly valuable and essential for successful integration into professional organisational environments [3].

InnerSource versus Open-Source: Which is suitable for Education?

A key question when discussing InnerSource in education is: Why not opt for open source instead? Many educational initiatives encourage students to work on real-world projects, making their contributions visible to recruiters and aligning with open research and open science trends. While InnerSource and open source share benefits such as collaboration, transparency, and practical experience, there are situations where InnerSource (initially closed) proves to be more appropriate in educational settings.

  • Project Completion and Later Open-Sourcing: Some projects require a closed environment initially, before opening up once they reach maturity.
  • Private Practice Environment: Students may prefer a closed setting to experiment without exposing early-stage experiments or mistakes publicly.
  • Research Contexts: Proprietary or confidential research projects require controlled internal collaboration spaces.

These scenarios demonstrate that InnerSource serves as a safe, structured first step before transitioning students to open-source workflows.

How InnerSource Works in Education

InnerSource in educational settings involves creating shared repositories for larger, common projects accessible across all course disciplines and student groups. These repositories centralise materials such as documentation, code, assignments, and student projects, promoting transparency and collaboration. Students from various academic years are encouraged to participate by submitting pull requests, refining peers’ code, and engaging constructively in peer reviews. Professors and teaching assistants supervise this collaborative workflow, ensuring high standards of quality and consistency while helping students develop essential technical skills and critical soft skills needed for modern workplaces. Expanding this model further, courses could integrate InnerSource practices into a broader, unified educational framework, imagining the entire degree as one interconnected “mega-project”. Each course would contribute distinctly defined components, collectively forming a holistic, collaborative learning experience. Although ambitious, such integration could significantly improve interdisciplinary collaboration and student motivation [4].

Benefits of Adopting InnerSource in Large Courses

InnerSource offers several significant advantages for collaborative learning in large educational environments:

  • Increased Student Engagement and Participation: Students are more likely to engage with course material when they work on real-world projects. The collaborative structure of InnerSource mirrors professional environments, fostering intrinsic motivation and investment in the learning process [5].
  • Realistic Simulation of Industry Workflows: By adopting InnerSource practices, students follow processes similar to those used in real software development, such as shared repositories, code reviews, and issue tracking. This realistic simulation helps them become familiar with industry-standard tools and workflows, better preparing them for professional environments after graduation.
  • Improved Motivation and Accountability: InnerSource introduces structured mechanisms for recognition (e.g., contribution histories, visible pull requests, and peer feedback), which can boost motivation. Knowing that their work is visible to peers creates a natural sense of accountability and encourages students to produce higher-quality contributions.
  • Development of Soft Skills: Working within InnerSource practices helps students enhance key soft skills such as communication, collaboration, and problem-solving abilities that are invaluable in modern workplace settings and often overlooked in traditional academic courses.
  • Iterative Feedback: Peer reviews and continuous feedback loops allow students to refine their work over time. This not only enhances technical skills but also improves their ability to give and receive constructive feedback, which is an essential professional competency.
  • Enhanced Transparency and Consistency: A shared repository increases transparency and ensures consistency in course content, assignments, and evaluations. Everyone works from a common source of truth. That said, it’s essential to recognise that some students and professors may still prefer to keep detailed evaluations or grading discussions private.
  • Reduced Workload for Professors and Teaching Assistants: As students begin to mentor and support one another, the overall burden on faculty diminishes. While this model may require some upfront planning and setup, it can significantly ease the workload in the long run by leveraging structured peer mentoring.

Structured Approach to Implementation

Given the scale of implementing InnerSource in large courses, a step-by-step approach is essential. Breaking it down into manageable phases allows for smoother adoption and effective scaling.

Phase 1: Training and Onboarding

  • Provide initial training sessions for students, professors, teaching assistants, and mentors (senior students) on the tools used for collaboration (GitHub, Slack, SonarQube, among others).
  • Set up shared repositories for course projects and assignments.

Benefit: This initial phase equips all participants with the tools and knowledge needed to start working collaboratively.

Phase 2: Small-Scale Collaborative Projects

  • Introduce smaller collaborative projects where students work together in teams. Begin integrating peer review and feedback loops.

Benefit: This offers a low-pressure introduction to collaboration, helping students build confidence and familiarity with the process.

Phase 3: Peer Mentoring and Iterative Reviews

  • Develop a system for peer mentoring, where students give feedback on each other’s work, using a structured peer review process.

Benefit: Peer mentoring helps lessen the workload for professors and teaching assistants while enhancing students’ communication and review skills.

Phase 4: Larger, Cross-Disciplinary Projects

  • Scale up to larger projects that span multiple courses, encouraging interdisciplinary collaboration. This step mimics the complexity of real-world projects, where different teams work on various components.

Benefit: Students gain experience in complex, interdisciplinary teamwork, reflecting industry-level project structures.

Phase 5: Evaluation and Recognition Systems

  • Create automated systems to track and assess individual contributions to the project (e.g., GitHub analytics, automated code reviews). Implement a structured recognition system for students who contribute significantly.

Benefit: This phase boosts motivation and accountability by clearly recognising individual efforts while ensuring fair, data-driven assessments.

Addressing Main Challenges

While the benefits of InnerSource are clear, several challenges must be addressed for successful implementation in academic settings:

Time and Workload for Professors and Teaching Assistants

  • Challenge: Implementing InnerSource demands significant time from instructors and TAS, especially when evaluating individual contributions across large, shared repositories.
  • Action: Automate parts of the assessment process using analytics tools like GitHub Insights or SonarQube, which can track contributions and support data-driven evaluation of student work. Structured onboarding and gradual adoption of InnerSource practices can help reduce workload.

Resistance to Collaborative Workflows

  • Challenge: Students may be reluctant to adopt collaborative workflows, particularly if unfamiliar with peer review or open contribution models.
  • Action: Provide clear guidelines, initial training sessions, and continuous support to help students transition to collaborative work. Regular development sprints, iterative submissions, and ongoing feedback can boost acceptance and foster a culture of open collaboration.

Managing Tool Access and Security

  • Challenge: Managing access to tools (e.g., GitHub, Slack) becomes more complex in large courses, especially when students need access to specific projects or repositories.
  • Action: Use integrated platforms that simplify access management and align permissions with project roles. Assign mentors to oversee project flow, ensure security, and help students use the tools effectively.

Maintaining Consistency and Quality

  • Challenge: Ensuring consistent code quality across contributions can be challenging when multiple students work on the same repository.
  • Action: Set clear coding standards and employ automated tools like SonarQube to maintain quality. Routine peer and instructor reviews reinforce best practices and encourage meaningful participation.

Fair Assessment of Individual Contributions

  • Challenge: Accurately evaluating each student’s input within collaborative projects is a common issue.
  • Action: Use clear metrics and regular assessment checkpoints supported by analytics from version control systems and peer reviews. Implement recognition systems to reward significant contributions, effective code reviews, or valuable suggestions.

InnerSource can replicate real-world development environments in academic courses. Students may work in specialised teams (e.g., backend, frontend, testing, among others) and collaborate to integrate their work into a larger product. Submitting and resolving issues, maintaining documentation, and participating in regular sprint cycles develop technical communication skills, promote proactive behaviour, and improve team dynamics. A structured recognition system for high-quality contributions further enhances engagement and motivation.

My Thoughts on the Future of Education

The future of education is collaborative, interdisciplinary, and closely connected to real-world challenges through strong industry partnerships. To prepare students for a swiftly changing world, institutions need to go beyond traditional lectures and encourage interactive, digitally integrated learning environments. Professors and teaching assistants will become mentors and facilitators, helping students develop critical thinking, creativity, and adaptable problem-solving skills while fostering genuine teamwork. Students, in turn, must adopt self-directed exploration, collaboration, and ongoing learning as essential 21st-century skills.

One practical approach to this transformation is implementing InnerSource practices, inspired by open-source software development. By working on shared projects, whether within a single course or strategically across multiple courses, students gain not only technical knowledge but also critical soft skills such as communication, coordination, and peer review. InnerSource offers a structured, safe environment for collaborative learning, which can later expand into open-source participation, allowing students to engage with global communities, showcase their work, and build professional portfolios.

Scaling these initiatives, especially in large courses, requires careful planning, clear guidelines, effective communication, and collaborative tools to monitor progress and ensure quality. Pilot programmes or integration with existing innovation projects can quickly demonstrate value without overwhelming participants.

As AI, remote collaboration, and rapid technological change continue to reshape how we work and learn, adopting innovative educational models like InnerSource is no longer optional; it is essential. A collaborative mindset is not just a bonus; it is a fundamental competency for the modern workforce. By adopting and integrating methods beyond Agile, such as InnerSource, institutions can expand collaborative learning, develop industry-relevant skills, and better prepare students to succeed in interconnected, agile, and dynamic environments. Now is the moment to lead this change, empowering students, professors, teaching assistants, and institutions to co-create the future of learning and work.

References:

[1] P. Dillenbourg, Collaborative Learning: Cognitive and Computational Approaches. Elsevier Science Ltd, 1999.

[2] OECD, Skills for Social Progress: The Power of Social and Emotional Skills. OECD Publishing, 2020.

[3] World Economic Forum, The Future of Jobs Report 2020. World Economic Forum, 2020.

[4] D. W. Johnson and R. T. Johnson, “An educational psychology success story: Social interdependence theory and cooperative learning,” Educational Researcher, vol. 38, no. 5, pp. 365-379, 2009.

[5] M. Prince, “Does active learning work? A review of the research,” Journal of Engineering Education, vol. 93, no. 3, pp. 223-231, 2004.

02.10.24
by

Thought of the day: Embrace Imperfection and Pursue Excellence

Recently, while reading Adam Grant’s enlightening book, “Hidden Potential,” I stumbled upon the term “wabi-sabi” (侘び寂び), which encapsulates the beauty found in imperfection, impermanence, and incompleteness.
 
Reflecting on this, I have realised the importance of setting challenging rather than perfect goals. In an Agility mindset, adapting and evolving based on constant feedback is crucial. By not striving for perfection, we open ourselves to rapid learning and growth, taking more risks and embracing imperfections.
 
In a fast-paced world of constant change, individuals and organisations must keep this mindset at the forefront. Instead of aiming for flawless solutions, let us focus on crafting workable ones with unwavering quality. Pursuing perfection can be a trap, hindering our progress by fostering a false sense of completion and stagnation.
 
Embracing imperfection fuels our journey toward excellence. Let’s remember that perfection is not the destination but a continuous learning and growth process.

07.28.23
by

Unveiling the Significance of Measure, Improve, Repeat: Empowering Agility in Today’s World

In today’s fast-paced and ever-evolving business landscape, organizations continually seek ways to optimize their processes and efficiently deliver customer value. One mindset that has gained widespread recognition for its adaptability and iterative approach due to its methods and practices is Agile. As an Agile practitioner myself, I firmly believe in the power of the Measure, Improve, Repeat cycle.

Photo by rc.xyz NFT gallery on Unsplash.

In this article, I will delve into the importance of this cycle and highlight a few potential downsides, ultimately emphasizing the significant advantages it brings to the Agile world.

Measure: Setting the Foundation for Success

At the heart of any successful Agile project lies the crucial step of measuring. Agile methodologies rely on gathering relevant data and metrics to gain insights into the team’s performance, identify bottlenecks, and gauge progress accurately. Through careful measurement, we understand what works well and requires improvement, enabling us to make informed decisions.

By establishing a robust measurement framework, Agile teams can track key performance indicators (KPIs) and metrics such as cycle time, velocity, and customer satisfaction. These metrics provide valuable insights into the team’s efficiency, the quality of deliverables, and the overall effectiveness of Agile practices within the organization. The ability to measure progress and adapt accordingly is paramount for continuous improvement.

Improve: Embracing Iterative Enhancements

Agile is synonymous with continuous improvement; the “improve” phase is pivotal in this iterative methodology. Armed with the insights gained from measurement, Agile teams can proactively identify areas of improvement and take actionable steps to address them. This collaborative and adaptive approach allows teams to optimize their processes, enhance productivity, and deliver better results with each iteration.

Continuous improvement in Agile is not limited to the development process alone; it extends to all aspects of the project, including communication, collaboration, and feedback mechanisms. By fostering a continuous learning and improvement culture, Agile teams can leverage their collective intelligence to find innovative solutions and adapt to changing requirements swiftly.

Repeat: Ensuring Long-Term Success

The final phase of the Measure, Improve, Repeat cycle, “repeat,” encapsulates the essence of Agile’s iterative nature. Agile embraces repetition rather than relying on a one-time process to achieve sustainable success. By continuously measuring and improving, Agile teams can iterate through cycles of development, feedback, and adaptation, ultimately enhancing the overall project outcomes.

Agile’s emphasis on repetition encourages teams to reflect on their successes and failures, refine their processes, and adopt a growth mindset. This iterative approach leads to a virtuous cycle of continuous learning, innovation, and high-quality deliverables.

Potential Downsides: Navigating the Challenges

While the Measure, Improve, Repeat cycle offers immense benefits, it is essential to acknowledge and address a few potential downsides. One challenge is the risk of analysis paralysis, where teams become overly focused on data collection and analysis, losing sight of the larger objectives. Additionally, continuously iterating and making changes can sometimes disrupt the project’s momentum, impacting deadlines and stakeholder expectations. It is crucial to balance measurement and action to avoid these potential pitfalls.

In conclusion, the Measure, Improve, Repeat cycle has emerged as a cornerstone of Agile practices in today’s rapidly evolving business landscape. By measuring key metrics, embracing continuous improvement, and repeating the cycle, Agile teams can foster a culture of excellence, adapt to changing requirements, and consistently deliver customer value. While challenges such as analysis paralysis and maintaining momentum exist, a mindful approach can help mitigate these downsides. Ultimately, the Measure, Improve, Repeat cycle serves as a guiding principle for achieving success in the Agile world, enabling organizations to thrive in a dynamic and competitive environment.

07.09.23
by

Agile Coaching 2.0: Myth or Reality?

Seven years ago, my friend Cornelius Engelbrecht and I made the decision to write an article titled “Agile Coaches: Myth or Reality?” (Link: https://beyondleanagile.com/2016/03/18/agile-coaches-myth-or-reality/). This year, while revisiting some of the oldest articles on the blog, I stumbled upon it and decided to create version 2.0.

Photo by K. Mitch Hodge on Unsplash.

The popularity of Agile methodologies has grown significantly in recent years, including in safety-critical domains, revolutionizing how organizations approach project management and software development. As a professional working in this field, I have often contemplated the effectiveness and impact of Agile coaching. In this article, we will explore the concept of Agile coaching, its alignment with the values and principles of the Agile Manifesto and examine several scenarios that may raise doubts about its existence. By considering these perspectives, we can determine whether Agile coaching is a mere myth or a tangible reality in the realm of Agile development.

Understanding the Agile Manifesto

Before delving into the myth or reality debate, it is crucial to revisit the core values and principles of the Agile Manifesto. The manifesto emphasises individuals and interactions, working software, customer collaboration, and the ability to respond to change rather than rigid plans and processes. These values form the foundation of Agile methodologies and provide a framework for effective project management and continuous improvement.

The Role of Agile Coaching

Agile coaching plays a vital role in assisting teams and organizations in adopting and implementing Agile practices. Coaches act as mentors, facilitators, and guides, helping teams embrace the Agile mindset, refine their processes, and navigate the challenges of an ever-changing landscape. Agile coaches empower teams to self-organize, promote collaboration, and drive continuous improvement, ultimately delivering high-quality software and enhancing customer satisfaction.

Scenarios That Cast Doubt on Agile Coaching

Despite its proven benefits, there are scenarios where Agile coaching might be perceived as a myth rather than a reality. Let’s explore a few potential reasons:

  • Lack of Commitment: Organizations that fail to fully commit to the Agile principles and values may undermine coaching effectiveness. When leaders and stakeholders are not aligned with Agile concepts or fail to provide the necessary support, the coaching process can become challenging, leading to scepticism about its value.
  • Resistance to Change: Change is inherently difficult, and Agile transformations require a shift in mindset and culture. If individuals within an organization resist embracing new ways of working, Agile coaching efforts may struggle to gain traction. In such cases, it may seem as though coaching is ineffective or inconsequential.
  • Inadequate Coaching Skills: Like any profession, Agile coaching requires a high level of skill, knowledge, and experience, including various methodologies and their implementation. Unfortunately, not all individuals who claim to be Agile coaches possess the necessary expertise. Instances where ineffective or unqualified coaches are involved can contribute to scepticism regarding the impact of Agile coaching.

In summary, Agile coaching is not a myth but a reality that holds immense potential for organizations striving to embrace agility in their processes. When implemented correctly, Agile coaching empowers teams to embody the values and principles of the Agile Manifesto, fostering collaboration, adaptability, and continuous improvement. However, the effectiveness of Agile coaching can be called into question in scenarios where commitment, resistance to change, or inadequate coaching skills hinder the transformative process.

To truly harness the power of Agile coaching, organizations must foster a culture of agility, invest in qualified and experienced coaches, and ensure buy-in from all levels of the organization. By doing so, they can leverage the benefits of Agile methodologies, improve product delivery, and achieve sustainable success in an increasingly dynamic business landscape. Agile coaching is not a myth; it is a valuable reality that, when embraced wholeheartedly, can propel organizations towards greater efficiency, innovation, and customer satisfaction.

05.19.19
by

Agile during the time of WAR and PEACE

When dealing with the methodologies of working, we hear a lot of interpretation and opinions.
Much of this feedback is constantly shared by members of our community, talking about the success or failure rates when adopting an agile methodology in their companies.

One of the much-discussed topics amongst us professionals is the reason why some companies are able to achieve success in transformation and others can’t. More importantly, what causes the initial enthusiasm and desire for improvement to quiet down and revert to the initial disbelief in the effectiveness of the methodology.

Having said that, a while ago I decided to write an article on this topic. I gathered all my thoughts and inputs collected both from businesses as well as from individuals with the desire to adopt an Agile Mindset and keep improving their way of working.

The moment has come to shed some light on what I think about this phenomenon.

I don’t remember who started this saying, but we all hear this quite often, “Agile is not the Silver Bullet”.

Photo by Velizar Ivanov on Unsplash.

The bullet concept reminded me of Lev Tolstoy´s famous novel, War and Peace. While we are not building here a literary commentary of the Russian masterpiece, we cannot overlook some similarities between Tolstoy’s characters and our modern-day corporate employees. Although situated in different centuries, both categories characters struggle with problems unique to their era, their history, and their culture in the process of adapting to the new times and changes.

What I’ve been observing is that two moments that can define weather adapting agile will be a success or a failure. In my experience, I call these moments the Time of War and time of Peace.

Photo by Vitor Pinto on Unsplash.

The Time of Peace…

Time of peace is what I consider to be the moment of engagement, specially buy-in from all stakeholders. Teams are split between being reluctant or enthusiastic about the change. At this point, the focus is on the benefits: predictability, transparency, empowerments, delivery at a faster pace. Potential challenges are acknowledged as being part of the journey until the moment of full transformation occurs. Even so, everybody is doing their best to take up the principles and values of Agile. The collective energy level is high, and this improvement process creates a new opportunity for people to build something together and become better at what there are doing while becoming a united and more autonomous team.

Photo by Eddie Kopp on Unsplash.

Teams are committed to making this work. Often times they repeat the mantra “Others did it, so why couldn´t we?”.

What amazes me is that they truly believe in the concept and are in fact doing all the work. Obstacle after obstacles, they are adapting and making it work!

Until…

The Time of War…

Photo by Specna Arms on Unsplash.

As so often specific for human behaviour, when the going gets tough. Everything is going well until this moment, the moment doubts or non-existing doubts appear.

What could happen to create this momentum?

Like most things having to do with human behaviour, this question does not have a single and ultimate truth as an answer. Environment, faulty processes and human nature all factor in.

From what I observed so far, it all gets down to pressure, the catalyst for a time of War.
Corporate environment can often times be a major influence. Pressure from upper management to see quick outcomes or ROI (return on investment), constant nudges from stakeholders powered by the fear of failure push the teams in untested waters too fast.
Broken processes leading to lack of transparency and communication on what, why and how to do will create further confusion and isolation.

Ultimately, the natural resistance to change, pushing too hard will lead to team burnout. And as always, not people but the concept will be to blame. An exhausted group of people will prefer to go back to what they know instead of spending more energy on fixing or adapting the “unknown evil” – this being in our case, the use of the agile methodology.

So, what is there to do?

I consider the breaking point of an adapting process to be when I hear the words “This doesn’t work for me”. Beyond this, there is no point of return. This is the moment that can make the difference between making this work or not.

I am a true believer of step by step, incremental changes. A Big bang approach puts far too much pressure on people and allows no real time for the mind to perceive and adapt to the new requirements. With small steps and iterative improvements “Time of War” moments can be dismantled, like a ticking bomb.

Across our adapting, we will have many “Times of War and Peace” but we need to keep our eye on the ball and remember that each “Time of War” it’s just one more obstacle we need to pass before getting over the finish line and make these principles and values part of our DNA.

With every obstacle passed, it gets easier.

Don’t stop here. This is just the beginning of the continuous improvement path.

Would be great to hear your thoughts on this topic.

Last but not least, we’d like to give a special “thank you” to Anett Stoica for the help with the article revision and all her feedback. Thank you!

04.07.19
by

My Podcasts at Scrum Master Toolbox Podcast

A few months ago I was challenged by my good friend Eddie Kenny and Vasco Duarte to participate in the Scrum Master Toolbox Podcast – A daily podcast for Scrum Masters and Agile Coaches.

I have accepted the challenge to be part of a podcast production while never having done anything similar before. It was not a simple as I have imagined, but with preparations and the guy´s support,  I was very happy with the final result.

To make it easier for you to follow, I’ve combined all 5 days content in one post below. To access the podcasts click the links bellow.

Hope that you enjoy listening as much as I enjoyed making them.

As always, feel free to share your feedback.

– Day ONE –

– Day TWO –

– Day THREE –

– Day FOUR –

– Day FIVE –

 

12.12.18
by

Enterprise Business Agility Maturity Survey

Some years ago, to be more precise in 2015, I had the opportunity to develop and implement an Agile Maturity Self-Assessment Survey.

The idea for developing this tool was driven by my strong belief in constant feedback, and it´s role in challenging the status quo that leads towards an improved and adaptive way of working.

Photo by rawpixel on Unsplash.

Another reason for designing the self-assessment survey was driven by one of the organizations I was working with. Their strategic objective was to focus on continuous improvement by growing our ways of working. The framework for this approach was based on constant feedback collection, agreement of improvement actions, and measurement of the achieved impact.

Thus, a self-assessment tool was needed, to provide realistic data that would lead our focus efforts. Most importantly, the source of data needed to come from those doing the day to day work.

After finishing the model, this was also published Scrum Alliance community as well as on the Beyond Lean Agile blog space.

Since its date of publishing, the survey has received a lot of feedback, adding my own experience while using it with various teams and organisations. The main points of improvements suggested were around making the survey generic so that it can also apply to non-development functions, less focus on Scrum, and customization of questions for specific areas.

In other words, be able to use to assess and understand the agile maturity level across the entire organization.

All the accumulated information drove me to sit down and review what I have created a couple of years ago. For a comprehensive result, I have done more research in the industry and asked people from several different areas do the assessment and share their opinion. All this input and research helped me take this survey to the next level – “Enterprise Business Agility Maturity Assessment”.

The goal of this iteration is to perfect a tool that helps understand the agile maturity level without limiting this type of assessment only to development or tech areas. Our main purpose as “agilists” is to improve ways of working by understanding pain points, to agree and prioritise what is critical, and keep our focus on constant improvement. The best way of doing this is to assess how known and widespread is the agile mindset across the organization.

While this new version has successfully been tested on a small sample, it would be deployed on a larger scale next year (FY19). Once tested, I will be happy to share the lessons learned and any improvement identified.

Having all said that, you can find bellow\here the “Enterprise Business Agility Maturity Assessment”:

———- Survey starts here ———-

Intro

Thirst of knowledge, willingness to fail fast and learn faster and keep improving are just some of the characteristics which embody agility, a concept that lies at the basis of customer satisfaction through continuous delivery. The agile mindset of leadership is the starting point that allows for the full formation of a highly collaborative and high performing culture.

As opposed to traditional top-down decision making or to a directive management style, leaders of agile culture focus their efforts on vision, strategy, growing people and removing organizational impediments. These agile values create an environment that supports empowered teams, allowing the specialists on the field to make decisions while aligning with the leadership direction.

Purpose of the survey: Define how present and widespread is the agile mindset across [Company Name] and identify existing opportunities for improvement and potential challenges to start adopting/proceeding with the agile transformation.

Guide on how to complete the survey: The survey is divided into 6 sections each of them containing a series of questions with single or multiple-choice answers. Where required, please provide a rating while using the guidelines below. All questions refer to culture and ways of working used here, at [Company Name].

Ad-hoc agile:

  • The organization mostly follows traditional processes.
  • Agile is either not used or used inconsistently across the organization.

 Doing agile:

  • The organization is just getting started with business agility.
  • Starts to exhibit some consistent agile habits.
  • Knowledge sharing begins to occur across the organisation.
  • Agile tools and practices are common.

Being agile:

  • The business agility basics are in place and more advanced methods are being explored.
  • Most of the project portfolio is agile.
  • Role and responsibilities are consistent across organization.
  • Disciplined, repeatable process is in place with high-quality results.
  • Trust in people/people empowerment and continuous improvement is occurring.

Thinking agile:

  • The organization has made significant strides towards business agility.
  • Agile habits are at a high maturity across the organisation.
  • Successful use of agile at scale and across multiple geographies.
  • Measurements systems are in place to track value realisation.
  • Automation is highly enabled.

Culturally agile:

  • The organization is a global business agility leader.
  • Lean and agile are part of the organizational culture.
  • Perfecting waste reduction, lack of overburden and inefficiency, smooth flow of delivery.
  • There is a sustainable pace for innovation.
  • Continuous organizational learning and optimization of ways of working is in place.

Select your business area from the following list:

  • TBD by you – Specify your organisation areas so the person is able to select from the multiple-choice option.
  • Which one? (Text field)

Leadership & Culture

  1. Are you clear about our organisation’s mission, vision and values?
  • Yes
  • No
  • Additional comments (Text field)
  1. Could you please identify and select at least three of our values [Company Name]?
  • TBD by you – Specify your organisation values so the person is able to select from the multiple-choice option.
  1. Do you feel that the leadership is communicating clearly in a timely manner?

e.g. How would you rate the leadership communication strategy and frequency?

  • Very dissatisfying (Ad-hoc agile)
  • Dissatisfying (Doing agile)
  • Neutral (Being agile)
  • Satisfying (Thinking agile)
  • Very satisfying (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate the leadership focus in identifying trends and opportunities for improvement?

e.g. Identify improvement opportunities to adapt and respond to constant changes.

  • No interest in seeking opportunities for improvements (Ad-hoc agile)
  • Low interest in seeking opportunities for improvements (Doing agile)
  • Compliance and process driven annual surveys with a low impact action plan (Being agile)
  • Periodic identification of opportunities with small improvements implemented (Thinking agile)
  • Regular/Periodic identification of opportunities with visible improvements implemented (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate the leadership’s openness to listen and welcome people’s opinions?
  • Doesn’t tell us much at all about what’s going on (Ad-hoc agile)
  • Gives us only a limited amount of information (Doing agile)
  • Keeps us adequately informed (Being agile)
  • Keeps us fairly well informed (Thinking agile)
  • Keeps us fully informed (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate the level of communication and collaboration within your business area?
  • Poor – only important information is shared with no particular collaboration happening (Ad-hoc agile)
  • Fair – information is shared but collaboration is not encouraged (Doing agile)
  • Neutral – information is shared regularly and collaboration happens occasionally (Being agile)
  • Very good – information is shared regularly and collaboration is happening when there are dependencies (Thinking agile)
  • Excellent – information is shared for transparency and collaboration is happening every step of the way (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your business areas’ communication and collaboration across the business?
  • Poor – only important information is shared with no particular collaboration happening (Ad-hoc agile)
  • Fair – information is shared but collaboration is not encouraged (Doing agile)
  • Neutral – information is shared regularly and collaboration happens occasionally (Being agile)
  • Very good – information is shared regularly and collaboration is happening when there are dependencies (Thinking agile)
  • Excellent – information is shared for transparency and collaboration is happening every step of the way (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate the organization’s approach in empowering people to take a certain level of decision and self-organized team level work?
  • No empowerment, people execute only what is cascaded from leadership (Ad-hoc agile)
  • Low-level empowerment only for work with small impact on strategic objectives (Doing agile)
  • Empowered to take major decisions and self-organize during occurred incidents (Being agile)
  • Empowered to take major decisions and self-organize business as usual work (Thinking agile)
  • Fully empowered, people have the power of decision and trust form management (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate the empowerment that you and your team have to try new things, without fear of blame?
  • No empowerment, the team executes only what is cascaded from leadership (Ad-hoc agile)
  • Low-level empowerment only for work with small impact on strategic objectives (Doing agile)
  • Empowered to take major decisions and self-organize during occurred incidents (Being agile)
  • Empowered to take major decisions and self-organize business as usual work (Thinking agile)
  • Fully empowered, a self-organizing team with trust from management (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your leaders support (feedback, mentor, etc) in continuously growing the team and achieving established goals?
  • Unsupportive (Ad-hoc agile)
  • Fairly supportive (Doing agile)
  • Neutral (Being agile)
  • Supportive (Thinking agile)
  • Very supportive (Culturally agile)
  • Additional comments (Text field)

Lean Business & Portfolio Management

  1. How do you think people perceive [Company Name] in terms of agile culture?
  • Ad-hoc agile
  • Doing agile
  • Being agile
  • Thinking agile
  • Culturally agile
  • Additional comments (Text field)
  1. How would you rate the efficiency of our customer’s interaction and communication?

e.g. Efficiency means: timely, frequent interactions, clear communication, specific guidelines.

  • Very dissatisfying (Ad-hoc agile)
  • Dissatisfying (Doing agile)
  • Neutral (Being agile)
  • Satisfying (Thinking agile)
  • Very satisfying (Culturally agile)
  • Additional comments (Text field)
  1. How would you describe the organization ability to cascade and provide clarity around business objectives (strategies/desired outcomes) and specific roadmaps?

e.g. Is data/info communicated clearly, visible and using a single source of truth, etc?

  • Doesn’t properly cascades information nor does it provide clear objectives (Ad-hoc agile)
  • Occasionally cascades limited amount of information with basic clarifications (Doing agile)
  • Cascades most important business objectives and provides clarity on vital roadmaps (Being agile)
  • Cascades information on a periodic basis and ensures visibility on business all area road maps (Thinking agile)
  • Communicates transparently all strategic objectives and offers consistent support to business areas (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate our planning vs demand capacity?

e.g. It’s visual and clear to everyone how and where people are allocated?

  • Very dissatisfying (Ad-hoc agile)
  • Dissatisfying (Doing agile)
  • Neutral (Being agile)
  • Satisfying (Thinking agile)
  • Very satisfying (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate our lead time to deliver business value to our customers?
  • Very dissatisfying (Ad-hoc agile)
  • Dissatisfying (Doing agile)
  • Neutral (Being agile)
  • Satisfying (Thinking agile)
  • Very satisfying (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your confidence in your team/business area achieving the current goals?

e.g. Do you feel that we are going in the right direction?

  • Strongly unconfident (Ad-hoc agile)
  • Unconfident (Doing agile)
  • Undecided (Being agile)
  • Confident (Thinking agile)
  • Strongly confident (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your team/business area responsiveness to changes and new requirements?

e.g. Is your team/business area flexible enough that can manage incoming requests?

  • Resistant (Ad-hoc agile)
  • Reluctant (Doing agile)
  • Neutral (Being agile)
  • Embraces changes (Thinking agile)
  • Agile (Culturally agile)
  • Additional comments (Text field)

Organisational Structure

  1. What is your team size?
  • 1-3 members
  • 3-5 members
  • 5-7 members
  • More than 7 members
  1. How would you classify your team level of skills in delivering business requests?

e.g. Can the team deliver business value with a high level of quality?

  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient, driven by continuous development (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your team/business area level of self-organisation?
  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Self-organising (Thinking agile)
  • Proficient in self-organising (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your team members’ ability to step outside their role and occupy different functions?
  • Ad-hoc agile
  • Doing agile
  • Being agile
  • Thinking agile
  • Culturally agile
  • Additional comments (Text field)
  1. How would you rate your teams’ ability to shift people upon demand?
  • Ad-hoc agile
  • Doing agile
  • Being agile
  • Thinking agile
  • Culturally agile
  • Additional comments (Text field)

Agile Mindset & Methods

  1. How experienced are you with working in self-organised, empowered, trust-based teams with shared outcomes?
  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient, driven by continuous development (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate the level of trust within your team and business area?
  • Very dissatisfying (Ad-hoc agile)
  • Dissatisfying (Doing agile)
  • Neutral (Being agile)
  • Satisfying (Thinking agile)
  • Very satisfying (Culturally agile)
  • Additional comments (Text field)
  1. What is your experience in leading and facilitating people-centric self-organizing teams?
  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient, driven by continuous development (Culturally agile)
  • Additional comments (Text field)
  1. How would you measure the level of opportunities to be creative and innovate?
  • Lacking (Ad-hoc agile)
  • Low (Doing agile)
  • Medium (Being agile)
  • High (Thinking agile)
  • Very high (Culturally agile)
  • Additional comments (Text field)
  1. How satisfied are you with your leader or team facilitator abilities to manage and remove impediments blocking you and your teamwork?

e.g. Does the team feel that they are stuck with issues outside their control?

  • Very dissatisfied (Ad-hoc agile)
  • Dissatisfied (Doing agile)
  • Neutral (Being agile)
  • Satisfied (Thinking agile)
  • Very satisfied (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your leader and/or team facilitator effectiveness in preparing, scheduling and facilitating agile ceremonies in an efficient and collaborative manner?
  • Very dissatisfying (Ad-hoc agile)
  • Dissatisfying (Doing agile)
  • Neutral (Being agile)
  • Satisfying (Thinking agile)
  • Very satisfying (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate the effectiveness of your team/business areas regular meetings?

e.g. Do you feel that they are valuable or a waste of time?

  • Very dissatisfying (Ad-hoc agile)
  • Dissatisfying (Doing agile)
  • Neutral (Being agile)
  • Satisfying (Thinking agile)
  • Very satisfying (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your visibility on the upcoming plans (backlog) for the next weeks/months (sprints)?

e.g. Do you have a clear and prioritised backlog or just what you are currently working on?

  • Very dissatisfying (Ad-hoc agile)
  • Dissatisfying (Doing agile)
  • Neutral (Being agile)
  • Satisfying (Thinking agile)
  • Very satisfying (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your team/business area skills to break down strategic deliverables to smaller, measurable business outcomes?
  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your team business analyst/product owner’s effectiveness in keeping the backlog and efficiently redefining and prioritising tasks?

Note: For corporate functions consider this role as the person organising the workload.

  • Ineffective (Ad-hoc agile)
  • Slightly effectiveness (Doing agile)
  • Average (Being agile)
  • Effective (Thinking agile)
  • Highly effective (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your team business analyst/product owner’s engagement with the team and knowledge in answering questions?

e.g. Is he/she available to the team? Is he/she engaging with the other stakeholders, and getting their input?

Note: For corporate functions consider this role as the person organising the workload.

  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient, driven by continuous development (Culturally agile)
  • Additional comments (Text field)
  1. How mature is your team in providing accurate estimations and planning for delivery?
  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient (Culturally agile)
  • Additional comments (Text field)
  1. How familiar are you in applying agile planning/estimating approaches (trade-offs, prioritisation, relative estimation, release plans, etc.)?
  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient (Culturally agile)
  • Additional comments (Text field)
  1. How often does the team receive fully detailed, ready to be implemented requests?
  • Rarely
  • Not very often
  • Neutral
  • Often
  • Very often
  • Additional comments (Text field)
  1. Does your team/business area have an agreed and clear definition of ready & done?
  • Yes
  • No
  • Additional comments (Text field)
  1. How would you rate your team/business area maturity in identifying and improving how you work?
  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient, driven by continuous development (Culturally agile)
  • Additional comments (Text field)
  1. Does your team/business area follow any of the agile frameworks/systems described below?
  • No, we still follow a traditional approach
  • Scrum
  • Kanban
  • Scrumban
  • Hybrid
  • Other – Which one? (Text field)

Performance & Measurements

  1. Are planned goals achieved in due time by the team?
  • Never – 0 – 15% of the time (Ad-hoc agile)
  • Rarely -25% of the time (Doing agile)
  • Occasionally – 50% of the time (Being agile)
  • Most of the time – 80% of the time (Thinking agile)
  • Always – 100% of the time (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your team/business area delivery pace?

e.g. Is your team delivering as fast as desired by your business analyst/product owner/costumer?

  • Unplanned pace (Ad-hoc agile)
  • Low pace (Doing agile)
  • Regular/Timed (Being agile)
  • High pace (Thinking agile)
  • Continuous /Seamless pace (Culturally agile)
  • Additional comments (Text field)
  1. How would you rate your team predictability (target vs actuals) deliverables?

e.g. Is the team within 90% of your target consistently?

  • Highly unpredictable (Ad-hoc agile)
  • Unpredictable (Doing agile)
  • Neutral (Being agile)
  • Predictable (Thinking agile)
  • Highly predictable (Culturally agile)
  • Additional comments (Text field)
  1. Do you feel that our metrics (KPI’s) measure what matters (valued indicators)?
  • Yes
  • If no, why not? (Text field)
  1. Do you feel that our KPI’s are fully understandable and visible?
  • Yes
  • If no, why not? (Text field)
  1. Are our metrics (KPI’s) providing relevant insights and used as a source for continuous improvement?
  • Yes
  • If no, why not? (Text field)

Make It Stick & Sustain

Leading a Business Agility transformation takes planning, time and effort and often represents a large investment. For the change to provide lasting value, it is important to “make it stick” and avoid falling back into old patterns and behaviours.

  1. Do you understand your role and what is expected of you?
  • Yes
  • No
  • Additional comments (Text field)
  1. Do you understand the other roles and what is expected of them?
  • Yes
  • No
  • Additional comments (Text field)
  1. How confident are you that your team/business area has the availability, tools and skills to meet their current goals?
  • Strongly unconfident (Ad-hoc agile)
  • Unconfident (Doing agile)
  • Undecided (Being agile)
  • Confident (Thinking agile)
  • Strongly confident (Culturally agile)
  • Additional comments (Text field)
  1. What tool does your team/business area use to manage work?
  • None
  • Physical board
  • Jira
  • Trello
  • Microsoft Excel
  • Other – Which one? (Text field)
  1. Do you have the right environments and automated tools?
  • Yes
  • No
  • Additional comments (Text field)
  1. Does the organization follow the right guidelines and practices to operate according to an agile mindset?
  • Yes
  • No
  • Additional comments (Text field)
  1. How would you rate the level of knowledge within the teams to achieve technical Excellency?
  • Novice (Ad-hoc agile)
  • Intermediate (Doing agile)
  • Skilled (Being agile)
  • Superior (Thinking agile)
  • Proficient, driven by continuous development (Culturally agile)
  • Additional comments (Text field)
  1. Do you have any suggestions on what [Company Name] our organisation could improve in terms of ways of working?
  • Open question (Text field)

———- Survey ends here ———-

It would be great to hear your thoughts and have your feedback about this survey.

Finally, I would like to give a special “thank you” to Anett Stoica, Diana Antão, Aurelie Rodrigues, Margarida Carvalho, Mike Sousa and Helder Pereira for the survey revision and all their feedback.

Thank you!

07.23.18
by

Is Agile really Dead? Myths and beliefs on what Agile means today

I would like to share with you our thoughts, here at Beyond Lean Agile, about a much-discussed topic in the community.

More and more people keep stating that Agile is Dead and we want to shed some light on this phenomenon.

Photo by Jonathan Bowers on Unsplash.

A few days ago while having my coffee break, a moment of the day I really enjoy, I was catching up on some of the articles I’ve been meaning to read, to keep up with news from the community and industry.

I was reading “So If Agile Is Dead, What’s Next… Flow? by Fin Goulding”.

Immediately after finishing the article I’ve challenged my great friend and colleague Mike Sousa, to write our own piece on why we think Agile is Not Dead and share our arguments on the topic.

Before getting started we would like to make a disclaimer:

  • What you are reading here is not a criticism to the article written by Fin Goulding, rather it was inspired by the topic he approached and the claiming that ‘’Agile is Dead’’ as so many others that currently are available. We strongly believe that having different ideas and opinions is what helps us to keep learning and improving. Through the article, we will present our thoughts and bring some balance and support to the true meaning of the Agile Mindset definition.

Up for a challenge?

Before we dive into the topic,  we challenge you to do a quick Google search about “Agile is Dead”. For sure you will see that nowadays there are a huge number of articles and talks on this topic.

Screenshot taken from Google Search about “Agile is Dead”.

As we see it, all the headlines in the news about “Agile is Dead” are creating a lot of confusion and some people are really believing that this death of Agile is because it doesn’t work. Many times Agile is implemented with lightness and incomplete, or with the belief that it will be the “Silver Bullet” to solve all the problems. This thought leads to drastic and hasty conclusions about the efficiency of the mindset/methodology while disregarding essential factors such as culture, environment and customization.

What are Agile ‘’CAPITAL SINS’’?

While browsing through the numerous google results from our ‘’Agile is Dead’’ search, we found many ‘’points of accusation’’ sustaining the concept.

Since the purpose of our article is to defend the status of ‘’not guilty’’ it is only fair to have a look at the aspects people find of faulty with Agile:

  • Using non-tech staff to manage projects reduces the quality of code and refactoring;
  • It has a range of inapplicability for more non-technical functions;
  • Attempts to scale Agile to reach strategy fell short;
  • As opposed to Lean or Six Sigma, Agile is meant to increase volume;
  • Instead of a framework, Agile is more a marketing tool;
  • Low visibility of the software utility and performance makes it impossible to calculate ROI before the development starts;
  • Systematic study and observation can teach organization and be able to differentiate between self-inflicted problems and those problems you can’t control;
  • Last but not least, the initial guiding principles lacked one essential element – having the Agile Mindset.

When going Agile, there are several challenges, from setting up individual teams to clearly communicating the benefits. However, the biggest challenge remains to get the interfaces working properly and make teams and the organization itself, leave the old ways of working and assist them in adapting what is new.

Let’s start with the basics…

Before we start drilling down into the subject of this paper, we would like to give some context and make sure everyone is on the same page.

If we do a quick search on “What is the definition of Agile” we find that Agile is the ability to move quickly and easily. This means that Agile helps us to achieve performance, innovation while delivering fast and obtaining customer satisfaction.

Agile doesn’t mean ‘’do/say” what I want nor does it commit faster without factoring in all the risks, dependencies while lowering the delivered quality.

We believe the issue with the statement ‘’Agile is Dead’’ starts with understanding what Agile really means.

There is another great definition saying “Agile enables organizations to master continuous change. It permits firms to flourish in a world that is increasingly volatile, uncertain, complex and ambiguous” from the Forbes article “What Is Agile? by Steve Denning”.

By coincidence, or not, Mike Sousa and I, attended the Agile Portugal 2018 Conference on the 25th of May 2018 and during the talk “Devops: The continuing evolution of operations” we heard Gareth Rushgrove share this Agile reminder:

Picture taken at the Agile Portugal 2018 Conference from the talk “Devops: The continuing evolution of operations” by Gareth Rushgrove.

So, why do people keep saying that “Agile is Dead”? Let’s think about what is Agile to us? What is our definition of Agile?

Agile is the founding mindset stone, based on which all the frameworks, systems and operating models are defined.

Photo by Martin Sanchez on Unsplash.

This means that before it all, what we really need is to understand the mindset properly and then develop the methods to adopt/do Agile in the right way.

After all, Agile is based on inspect and adapt (continuous improvement), culture, trust, collaboration and delivering value. This for us is the most basic Agile definition. All next steps can be adapted.

Why we say this?

It’s simple… Should we stick to a standard framework, system or operating model? Or should we be Agile and first of all understand what is the problem we are trying to solve and customize what operating model works for our business reality?

Let’s take a look at Spotify. Did they follow/adopted an existing operating model or did they go an extra mile to really understand what the problem was they wanted to solve? They went the extra mile and customized their operating model (Spotify Tribes Model) to respond to their real needs. Also, did they stop or did they continuously improved their operating model to constantly respond to their needs?

Like Spotify and Amazon, we have more companies that keep improving their ways of working every day so they can constantly exceed their goals.

So, returning to the Agile ‘’CAPITAL SINS’’. This is why we believe that the sins are not real:

  • Using non-tech staff to manage projects reduces the quality of code and refactoring;

Using non-tech staff to manage projects does not reduce the code quality since they shouldn’t be the ones writing or reviewing the code. There is a reason why there are different, well-defined roles when using any Agile methodology, so we can use the strength from each role and create dynamics. Diversity is what makes a team, project and business to succeed.

  • It has a range of inapplicability for more non-technical functions;

As we shared above, for us Agile is a mindset, the founding mindset stone. This means that any framework, system or operating model can be applied to any area and/or business.

For more details and examples please check our previous article “Can Agile be adopted by non-software development areas?”

Most of the attempts to adopt or scale Agile fail because we are missing the most important point that is understanding what it really means. Understanding that Agile is about seeking to get better by continuously scanning the environment/process while empowering people to do so is the key element into extending the concept to a strategic level. It is people’s by in adopting the mindset that will allow large-scale success and focus on what is actually important for the business. The Agile Mindset helps tailor successful custom solutions and copy-pasting something designed for an organisation with different goals and challenges.

  • As opposed to Lean or Six Sigma, Agile is meant to increase volume;

Agile is the founding mindset stone also for Lean and Six Sigma since it provides the ability to move quickly and easily. It empowers organisations to respond to the constant changes and increase “customer satisfaction”. While a highly efficient and autonomous team will produce more in a shorter time, the end goals are to optimize resources, reduce waste and increase customer satisfaction.

  • Instead of a mindset, Agile is more a marketing tool;

Unfortunately, in many cases this is true. Nowadays people are selling Agile as a silver bullet solution since companies are being forced to “become Agile” due to the high trend in the industry. Being Agile is the magical word or the catchphrase that seem to be attracting more investments or increase sales and success rate.

Quoting Todd Little from the Forbes article “What’s Missing In The Agile Manifesto: Mindset” by Steve Denning.

“The first line of the Agile Manifesto is about valuing individuals and interactions ahead of tools and processes. Yet what do we see being sold in the marketplace, but processes and tools? Agile has become way too much about processes and tools, partly as a result of the way the economic engine works. People are looking for, and buying, processes and tools, when it should be about the Agile mindset.

That’s the challenge we face in keeping Agile truly Agile.”

We also have some common experiences were companies hired consultants to bring or define the  “magic solution”. However, after implementation, these companies declare themselves as being Agile, while in reality, they operate more or less the same while having invested in a concept that will not work if people don’t incorporate the mindset.

  • Low visibility of the software utility and performance makes it impossible to calculate ROI before the development starts;

We can forecast ROI but this will remain an estimation calculated for possible scenarios. While we are aware that ROI is in most cases a financial measurement of success, we are also focusing on the less tangible gaining’s. What could be a higher ROI than small and fast iterative deliveries with the capability to constantly have customer satisfaction? With these small chunks of continuous deliveries, companies have almost immediate ROI and the possibility of increasing product/service value by adding constant and real feedback.

  • Systematic study and observation can teach organization and be able to differentiate between self-inflicted problems and those problems you can’t control;

Systematics studies and assessments are important for gathering data and preparing us to respond to problems especially to the ones we can control. This data gives the ability to constantly inspect and adapt to the real work is – this being actually the Agile Mindset in action. We need to keep in mind that there is not always to problems exactly the same that the same solution will work. The world is constantly changing and problems evolving into different ones due to the higher and hard competition. As we can see what worked 10, 20 or more years ago is not working nowadays anymore.

  • Last but not least, the initial guiding principles lacked one essential element – having the Agile Mindset.

As explained above, we can say that we embrace Agile, that we follow the values and principles but if we don’t have the mindset record in our mind we have a breach to Agile adoption fail with time. This is something that we believe that we need to understand, believe and breed.

Does this mean that Agile is Dead?

Off course not! 🙂

Agile is not a framework, system or operating model, is much more than that!

We understand that the word is imprecise and many people really don’t understand or misuses it. Still, this is why we emphasize the fact that understanding and truly adapting the mindset sits at the bottom of a successful implementation. Moreover, we want to help people understand what Agile really means and testify that it can be the solutions for a smooth and sustainable continuous improvement process.

It would be great to hear your thoughts on this topic.

Last but not least, we’d like to give a special “thank you” to Anett Stoica for the article revision and all her feedback. Thank you!

#agile #agilemanifesto #agilemindset #agileadoption #agileisdead #forbes

07.12.18
by

Agile Online our new online community

Hi Portuguese and all Agilists!

Yesterday I had the pleasure to attend a live webinar (Descomplicando Agilidade) hosted by our Agile colleagues from Brazil.

One of the discussed topics was about the communities around the world, in particular, how they work and their challenges.

This discussion made me realize that we do not have an online community/channel where we can bring everyone together to share experiences and ideas, so we can all learn and grow together.

Having said that, I would like to share that I’ve created a Slack Channel called “Agile Online” as an action inspired by the discussion mentioned above.

Thanks to the Brazilian colleagues for the great tip!

Do you want to join this new community? Use the following link (Agile Online Community) to join and don’t forget to share the link with all Agilists.

Disclaimer: Please don´t use this channel to sell training or consultancy.

#agile #agilecommunity #agileonline #agilists