I’ve been having a very interesting twittervation about how to start teams off with Scrum. I believe you best learn by doing. And that it’s more important to get teams actually starting Agile in the workshop than merely learning Scrum which will hopefully lead you to Agile.
So we “teach” Scrum with a 1-day emulation and discussion of it followed by 3 days of ATDD. This first day teaches the essence of Scrum but it illustrates how teams work – mostly their foibles. 🙂
The other three days are on ATDD. Each day isi split by 1/2 day discussing it & then an hour with each team doing it. What we’re really teaching is – collaboration, test-first, feature slicing, and how to use minimum business increments. These directly address the issues we’ve seen most teams have- unclear requirements, stories too large, POs not appreciating the impact of interruptions and a lack of focus on finishing.
The test-first is mostly about discovery & specification but it also informs design (the 1st mantra of design patterns is designing from behavior).
The result is that once a team gets moving they can keep moving. But a course that prepares you for movement may not ever get you started.
I’ve always been bothered by the dismissal of XP as just being “Scrum with tech practices.” But the differences between the two are much greater. First, while XP and Scrum both have related values, the practices of XP are mostly centered around sw development practices (such as paired programming), while Scrum is mostly about non-domain specific team practices. Second, XP includes Acceptance Test-Driven Development (ATDD). ATDD, which is a collaboration between the Product Owner, dev, and tester and which includes neither design nor coding and is therefore, not a technical practice. In other words, Continue reading “XP is not Scrum with tech practices & knowing why this is so is more important than ever before”
Many people think of Acceptance Test-Driven Development (ATDD) as an advanced practice. Others think that using Given When Then (GWT) from Behavior Driven Development (BDD) requires the use of tools. Neither of these are true however. The easiest way to start using ATDD and/or BDD is simply to ask the question “How will I know I’ve done that?” whenever you are given a requirement – even if the requirement appears to be obvious. The reason for this is that it is often the ‘obvious’ requirements that are most misunderstood. Continue reading “When given a requirement ask the question, “How will I know I’ve done that?””
If you are kicking off new teams there are two types of coaches you can bring in. While it’s useful to bring in someone who can actually help with the work, such as a technical or ATDD coach, when it comes to Scrum or Agile coaches it’s usually better to grow your own. There are several reasons for this:
Continue reading “Why you should grow your own Scrum Masters instead of bringing in outside coaches”
Which initial training you chose should therefore be that teams can do this after their initial training. The promoted belief that you should focus on the framework & then learn how to do this later is not just self-serving, it is wrong. While you can take a course and then pay for coaching after the workshop to learn this is not just expensive but wastes the time of your staff and often produces resistance. Continue reading “The #1 challenge for teams after Scrum training is writing small, well-scoped, testable stories”
First, let’s be clear what we mean by Acceptance Test-Driven Development. It does not mean automating testing. It means to collaboratively (Product Owners, devs and testers) working together to go from features to small stories (less than three days) that are well-scoped and have clear acceptance criteria that could be automated if desired.
Most companies delay ATDD because CSM and team level courses for SAFe don’t include it. The trade off is more framework and less actual Agile work. Continue reading “Why it’s so important to learn ATDD upfront”
At Net Objectives we’ve been leading with Agile Product Management for 13-14 years. Borrowing from Denne and Cleland-Huang’s Minimum Marketable Feature we created the term Minimum Business Increment which is the smallest chunk of value that can be realized that makes business sense. It is not about delivering less, but delivering sooner. Continue reading “Why you need to lead with Product Management regardless of your Agile approach”
We have created a new team-level course that integrates about 1/2 of a Scrum Master class with a full-blown Acceptance Test-Driven Development (ATDD), using Given When Then that has been remarkably successful. The mantra is “focus on the work, not the framework.” Continue reading “Why you need to start with ATDD with SAFe even more than with Scrum”