13 Effective Ways for Scrum Masters to Build Happy Teams

In 1986 Hirotaka Takeuchi and Ikujiro Nonaka published The New New Product Development Game in Harvard Business Review. They described a groundbreaking approach to complex product development. In the article, they borrowed the word "Scrum" from the game of Rugby. The analogy of product development to a game is quite interesting here. A team can achieve full potential if they are enjoying their work, like players playing a game with fun.   

Scrum masters can facilitate the ways to create this fun element in their team’s day to day work. Following are some actionable techniques which can help in doing it:   

Agile Transformation Challenges: 6 Missteps That Slow Down Change

The road to a successful Agile transformation is not an easy one. As the number of organizations deciding to embark on an Agile journey increases, how many of them are successful? VersionOne’s 13th Annual State of Agile Report states that 97 percent of respondents surveyed practice agile to some degree within their organization. However, only practicing the methodology to some degree, is one of the most detrimental mistakes organizations make, hindering the chances of a genuinely successful transformation. 

The number of obstacles that stand in the way of organizations achieving desired results is exponentially higher than those faced by start-ups. Some challenges, like size, are beyond their control. However, there are common challenges that enterprises can avoid if they know what to look for. 

What Is a Scrum Master?

The globalized business landscape means that most companies are on-demand, all the time. The product development process needs to be highly customer-centric to achieve success, and companies have evolved different methods to address this need.

The most popular way for companies to accomplish their goals is through the adoption of the Agile Scrum process. Over 80 percent of organizations use the Scrum framework, but there are vast differences in the way it is implemented across various organizations.

Accelerating Agile With Serverless

"Intelligence is the ability to adapt to change." These are words from the great Stephan Hawkins and can justly encapsulate the core meaning of the Agile concept which has revolutionized the way we conceptualize and produce software. The tech industry has gone through sweeping changes that have resulted in expeditious software production. Gone are the days where software teams would spend months and even years to deliver on new features to improve the experience of their customers. Now, changes can be implemented in a matter of weeks, if not days. A major push towards the change has been due to the maturing of cloud services and CI/CD practices.

Serverless is the latest trend in cloud computing, a technological concept that, if understood and implemented properly, is one that can further our movement towards true Agile development. Therefore, the aim of this piece is to revisit the core concept of Agile, go through the developments in the tech industry and highlight the future of Agile with serverless as a practical base.

Unified Agile-DevOps Transformation Model, Framework and Executable Roadmap for Large Organizations

Abstract

Agile-DevOps transformation and Continuous Delivery became the leading topic and highest priority for senior leadership, stakeholders, teams and customers alike. Agile-DevOps transformation is a fundamental change to the organization's culture, structure, people, and business/technical paradigms towards the next level of agility. It relies on Lean values and principles, and brings the highest level of collaboration, productivity, quality, flexibility and efficiency, cutting-edge technology, and competitive edge to your organization.

While some organizations succeed in their transformations, others fail. Agile-DevOps transformation can be ambiguous, disrupting, misdirecting, and even harmful if executed without the right guidance or led by the wrong people. Transformations primarily fail for two reasons. The first is the lack of a common vision, strategic approach and unified transformation model, framework, and roadmap that inhibits the agreement between change agents, leading to the inability to arrive at a single voice on how to orchestrate and implement change. The other is the agents’ limited knowledge and expertise or a tendency to follow on a previous success path regardless of the organization's uniqueness.

10 Common Scrum Mistakes and How to Avoid Them

When most people think of Agile, they think of “Scrum”.  Scrum is the most widely used, and arguably, the most abused Agile framework.  Scrum is simple in concept but can be difficult to do really well.  Here are 10 common Scrum mistakes and how to avoid them:

1. Expecting Transformation to Agile and Scrum to Be Easy

All too often, someone will pick up a book on Agile or Scrum, start chopping up requirements into user stories, begin daily stand-up meetings, develop software in 2-3 week sprints, and then call themselves Agile.  Easy, right?  They will likely see some improvement in their ability to respond to change, and may even provide working software faster – for a while.  It won’t be too long, though, until the promises of Agile become less evident, teams struggle to keep up the pace, software doesn’t always match user expectations, and then Agile is deemed a failure.  Agile transformation takes time and almost always starts out messy.  Real transformation exposes existing corporate and culture problems that must be dealt with – problems such as poor communication, lack of accountability, distrust, etc.  Effective Agile transformation is often a total culture change.  Give it time, and be ready to go through the pain and resistance to cultural changes.

Agile Documentation: Fact or Fiction?

Documentation in an Agile environment is an interesting topic. The Agile Manifesto places more value on working software than on comprehensive documentation, and one of the Agile principles states, “Simplicity–the art of maximizing the amount of work not done–is essential." But does this mean we shouldn’t write documentation when we use an Agile framework? Not at all. I use these three key practices to create effective Agile documentation.

Minimize Artifacts

First, minimize documentation to just what’s needed to get the job done. While software solutions must be maintained and need supporting documentation (either as commented code or external documentation), there is a tendency to create documents simply because “we’ve always written them," whether they are ever read or not. Creating unneeded documents expends valuable time and is counter to delivering the highest value first. Documentation effort should be treated like a requirement if it’s not part of your Definition of Done; it should be estimated and prioritized along with other work. This means weighing the cost of documentation against the anticipated benefit.

Agile Adolescence: The Gawky Teenage Years

As an Agile Coach, it’s exciting to watch a team of young agilists start their Agile journey. Some start with unbridled enthusiasm, others with fear and trepidation. They then crawl from Agile infants to toddlers learning how to communicate and play well with others, then move into Agile childhood where they begin to develop competencies and enjoy success. And then… [long pause] …they become Agile teenagers – yikes!

Don’t get me wrong – I’ve raised one teenager and have another now, and I love them even during their teenage years. There are great times at that age, and there are, well, less than great times too. Those growing in their agility go through stages similar to what my kids did. Some move through the teenage years with grace and style, some with a rebellious attitude, and unfortunately some stay in Agile adolescence way longer than they should. Being an Agile teenager is normal for a while, but just as we don’t want our children living in our basement, playing video games and eating Cheetos well into their 30’s, at some point every Agile teenager needs to grow into adulthood.

Managers and Agile: Where Do I Fit In?

Agile is about self-organizing teams, isn’t it? As a Manager, what does that mean for me? Should I fear for my job? As a Manager or Director, Agile transformation can be disconcerting because you want to trust your teams and let them be self-organizing, but at the end of the day, it’s still your organization and your responsibility.

Let’s start with a proper view of the term “self-organizing”. Many leaders and teams incorrectly think that self-organizing teams don’t need leadership. Agile is about flexibility, not anarchy. Esther Derby explains it well: “Self-organizing is a characteristic of a team, not something that is done once and for all. Self-organizing teams experiment, create new approaches and adapt to meet new challenges within the boundaries of the organization.” Mike Cohn says: “Self-organizing encourages teams to fully own the problems they encounter.” Empowerment is the key to self-organizing. Management must empower Agile teams to experiment, fail and learn, which in turn gives team members higher personal investment in outcomes. Agile pays people to think, rather than to blindly follow instructions.