The 2015 State of Scrum report

The 2015 State of Scrum ReportThe Scrum Alliance just released their updated State of Scrum report based on their investigation of the industry. The survey uncovered findings that not only reflect where Scrum is today, but what we can anticipate it will look like tomorrow. These include who is practicing Scrum, how they are practicing it, success levels associated with Scrum, and plans for its continuing use.

Report statistics provide intriguing insights and information such as:

  • 87% say Scrum improves teams’ quality of work life    
  • 81% believe certications improves the practice    
  • On average, Scrum is successful 62% of the time    
  • 95% will continue to use Scrum

The report is free to download from the Scrum Alliance site.

Speaking at Agile2015

We are excited to be speaking at this year’s Agile Alliance conference in Washington, August 3-7.  With nearly 17,000 members and subscribers around the globe, Agile Alliance is driven by the principles of Agile methodologies and the value delivered to developers, organizations and end users. 

Speaking at Agile2015Richard Dolman will present his discussion on Backlog Refinement (the Scrum ceremony that “gets no respect”) while Dhaval Panchal together will Thomas Perry will invite attendees to share unsettling questions about prevalent management practices in Swarming: The Birds, the bees and Agile -or- How Managers influence self-organization.

The event is sold out and we’re expecting a packed house for each of these talks. Are you attending? If not, we will report on the event as soon as possible.

Talking about the 3 stages of scaling Agile organizations

I have been the guest on a recent episode of the Agile Chicago Style podcast
to discuss with Rick Waters the different stages of scaling Agile
organizations. It’s not necessarily all about making your Agile
footprint bigger, ideally it’s about making it better (and then bigger
later).

It’s been a lively discussion with great leading questions and we discussed some of the things we are actively working on as part of our Agile at Scale training offer and the agile42 Enterprise Transition Framework™.

Agile Awareness per startup TIM #WCAP

La settimana scorsa abbiamo partecipato al processo di formazione delle startup del programma di accelerazione TIM #WCAP 2015 nelle quattro sedi di Milano, Bologna, Roma e Catania. La nostra giornata di Agile Awareness Training ha consentito di illustrare i fondamenti del metodo di lavoro Agile e come si possono adattare alla vita di una startup.

TIM #WCAP Catania, foto di Luciano De Franco via Twitter

La giornata intensa ha visto spiegazioni alla lavagna, molti post-it e com’è tradizione di agile42 giochi e momenti interattivi di gioco con il Marshmallow Challenge, il Magic Balls Game, la simulazione di un processo Kanban e molti altri.

Il nostro training Agile Awareness è a disposizione di business manager, executive manager, project manager e di tutti quelli interessati a capire come un modo agile di lavorare può migliorare i risultati del loro progetto.

Follow agile42 on social networks

The raise of social networks has been tumultuous in the past few years, and the Agile community has embraced them with gusto, finding new ways to discuss and coordinate efforts, and also to promote methodologies and theories. If you like the updates we post on this blog and you want to keep constantly in touch with agile42 we have a presence of a number of networks as well but sorry, no Instagram profile: we are not picture-pretty (yet).

You can follow us on Facebook and Google+, you will find posted our latest article and news with comments from our large community of students and coaches. On YouTube the agile42 channel is home to short videos where our coaches introduce Agile concepts and thoughts, and to longer recordings of talks at conferences and events.

Illustration by Yoel Ben-Avraham

Have you ever noticed how Twitter is loved by Agile experts and practitioners? From jokes to quips to full rants you can read updates from the top personalities of the Agile worlds and organizations like the Scrum Alliance. Of course agile42 is present on Twitter where we link new and archive blog posts, training news and engage with our 3,000+ followers. Most of our coaches are on Twitter as well: follow them all through this list.

Last but not least, LinkedIn is the largest professional network in the world and we have a company presence in there where you can read and comment updates on our latest activities and keep in touch with our coaches.

And thanks for your continuing support!

Illustration by Yoel Ben-Avraham – http://flic.kr/p/fQ6CnH

Definition of Done : Why it matters?

Acceptance Criteria -vs- Definition of Done.jpg

One of the first things we recommend new Agile teams establish is what’s called the “Definition of Done”.  The DoD is crucial to highly functioning Agile Teams in helping them develop practices and behavior that drive quality, consistency and transparency.

Why it matters

A useful product has two key aspects. Features in this product are not only useful to users but are also usable, in other words, features actually work. The product owner and stakeholders help the delivery team understand the “right thing” to be developed and the delivery team uses their development expertise to build it the “right way”. Both these dimensions are crucial for any product development.

Right-Thing, Right-Way:These are features that are desired by your end-users and they work the way they are supposed to. These features are conceptually coherent with the product, and also built the right way, such that they are stable and do not cause technical instability in the product.

Right-Thing, Wrong-Way: These are features that are desired by the users and they use these features. However, since these are not built the “right way” they do not function the way these are supposed to. When features are not tested they fail to perform their utility. When features are implemented without cognisance to end-user context and behavior, or when the team developing the features lacks *competence* and discipline, we create products that are buggy. These issues hamper the ability for end-users to get their job done and leads to waste and higher costs. As one executive, so aptly pondered out loud “Why is it that we never have time to do it right! but have time to do it again?”.

Wrong-Thing, Right-Way: These are the features that your end-users do not know exist. They may have been built the “right way” but then these features are not discovered and not used. These are ghost features that are silently increasing product engineering complexity. In Extreme Programming, the prioritization principle of YAGNI (You ain’t gonna need it) is intended to counter unfettered stakeholder desires and implement only features that are needed, now!. Deferring commitment for features is a good strategy since we all know, unlike tomatoes we don’t sell software by the pound.

Wrong-Thing, Wrong-Way: Wrong features built the wrong way are cancerous cells that eat up developmental capacity since these cause issues with well functioning parts of the product. This causes erosion of development capacity for the team as the team gets sucked into bug fixes only to discover that issue stems from an area of the product that no one uses. These features erode team morale. Lack of team discipline has lead to accumulation of technical debt and feature creep creating an untenable situation. Such legacy areas in a product are universally feared.

The Definition of Done (DoD) expresses the “right way”, a checklist that asserts quality of the product and the workmanship of the delivery team. Acceptance criteria accompanying a User Story, or a feature requirement represent the “right thing”. Getting both these aspects of product development right are important for sustainable and continual product growth. It requires collaboration, trust and feedback with and amongst the delivery team(s), product owner and stakeholders.

 

 

How Do I Know Agile is Succeeding?

Thumbs Up

When talking to potential customers, we often get told that a team or program has been ‘agile’ for months, or even years. It’s not uncommon for us to find teams applying those agile practices we associate with successful teams: retrospectives, shared code ownership, decent product management. Unfortunately, this does not necessarily translate into what we consider to be a successful agile delivery process. So this got us thinking:

  •  What does a successful agile team or organization look like?

  • How do we know a good agile team when we see one, or a great agile organization when we see one?

 

Here’s what to look for:

1. Listen for the ‘Why’

Becoming agile is a cultural shift, not a tactical shift.

The practices are the how, not the why. Just as Simon Sinek points out, it’s all about the why.  A cultural shift is made visible through the conversations we overhear and the discussions and communication between teams, rather than the practices we observe in the teams. Therefore, in order to understand how well a team or project has adopted agile we want to listen to how they communicate, not just focus on the practices they are using.

2. Improve learning capabilities

The goal of adopting an agile mindset is a to develop a capability, not reach a destination. We don’t want teams to aim for “50 points per sprint”, or a “release at the end of each sprint”. The objectives are new skills and ways of working that allow the team to learn and grow, not measures of activity or productivity. Here, we do look at practices. What skills are the teams building? What capabilities do the teams have? Not efficiency or productivity skills and capabilities, but learning and experimentation skills and capabilities.

So, now that we know what to look for? How can we identify successful agile teams?

Here, we ask two questions:

Do you focus on value delivery or activity and productivity?

Are you continually learning, able to continually refine and adjust a living work delivery process?

Value over Activity

Agile frameworks, from Lean Startup to Extreme Programming, are focused on the rapid delivery of customer value. Every aspect of each framework starts with the assumption that the teams are working as hard as possible. The level of contribution is not in question. Therefore, what is delivered becomes the primary concern. In agile organizations, the cultural noise we hear is focused on the delivery of value rather than comparing activity or productivity. Teams talk about the features they released, and how well (or not) the customers valued (used, paid for) the new features. It’s not a race to do the most work, or have the most number of features, but to provide something the customers need and value.

One of us (the Englishman) is a big fan of the English Premiership. The successful teams are those that grind out results against unsexy, mid-table opposition, many times against the run of play. We often hear the teams that win the Premiership described as boring or being able to grind out ugly wins (Chelsea or Manchester United, for example); winning games by one goal even though they played poorly. On the other hand, there are teams that play some of the best football on display in any league, with an incredible strike force or elegant build-up play (stand up Arsenal) and still do not win.  The hard reality is that these teams lose sight of the value – winning games – because they are focused on elegant activity, on quality and on productivity.

We want to hear about the value delivered – the games won – not the productivity of the team. Conversations revolve around how to get value to the customers, how to understand what the customers need, and how to deliver that value quickly, with the minimum of fuss.

Experiments are the New Black

Agile organizations are continually learning, basing decisions at all levels on small experiments in which they learn something about how to move quickly toward their goals. This focus on continually learning through micro-experiments extends throughout the organization, from how the teams work to what the teams work on. Agile development teams can use it to determine if a new practice will help them deliver better quality code and Product Owners can use it to determine if customers will really use the great new feature they’re developing. Continually learning is predicated on designing a small change, and testing whether that change improves your outcomes or not. Keep the ones that move you forward and change the ones that hold you back.

As groups make the transition from doing a lot of work to doing the right work, one obvious question always comes up: How do we know what the right work is?

It is a natural tendency in many organizations to use assumptions to make these decisions. Perhaps you’ve heard comments around your company like “everyone knows that…”, “none of our users…”, or “everyone’s code includes…”. Yet you wouldn’t plan a road trip from Seattle to New York by assuming any road going east will get you there, so why would you base critical decisions on assumptions about your business or customers. Instead, agile organizations target these assumptions and find the true answers before making their decisions. In Eric Ries’s Lean Startup book, this practice is aptly referred to as Validated Learning.

Most organizations will transition from assumption-based decisions to validating decisions in hindsight. As the organization gets better at framing their validation experiments in smaller pieces and gets more proficient at extracting informative data out of their experiments, they will begin to be more proactive in their validated learning.

Don’t Take Anything for Granted, Even Agile Practices

A case in point. Many new agile teams struggle to complete valuable work within the sprint constraints of Scrum. One team we worked with wasn’t sure that well-defined user stories with acceptance criteria would really help resolve this challenge for them, so they created an experiment around it. For the next month (two sprints for them), the team and Product Owner would commit to a strong definition of ready, creating a clear understanding of what the team was being asked to deliver. In the sprint reviews, if the resulting work from each story matched what the end user was looking for, they’d know that this practice was effective in solving their problem. On the other hand, if they kept missing the mark and incurring expanding scope on their work, they’d know that this practice was not enough to help them deliver value in their sprint. This was a short, well-defined experiment that helped the team take a step towards owning their delivery process.

Conclusion

Adopting agile is a journey and every organization is at a different place in that journey. So  how do you know you are moving along in the right direction, at a decent pace without too many detours?

We believe you have to listen out for two things:

  • How often are you talking about (and following through) on value delivery to the customer? Remember value delivery is more important than productivity.

  • How many discussions do you hear on the experiments that teams are working on? Remember, Status quo is not the goal, but the baseline; continual learning and improvement is the goal.

So, how well are you doing? Join us on LinkedIn to continue the discussion! (agile42 #WhyAgile Discussion Group)