Gojko Adzic

author
+ Follow
since Sep 07, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Gojko Adzic

Raja Pal wrote:Dear Agilists,
Gojko, Does SBE follow any of the methods of these practices or is it a different approach altogether?



I don't really know anything about those certification programmes.

Zico Gupta wrote:Hello Gojko,
The problem is the product owner himself is not well versed with the complete product, on the other hand, management is not ready to expose team members directly to the customers. We only get a chance to interact directly when a bug arrives.



Several teams I interviewed for Specification by Example got their product owners to supply initial examples directly from customers/business users. the team then worked with the PO to clarify more examples and the PO would get that confirmed by the customers/business users after a spec workshop. In such cases you might want to run the spec workshop a few days before the iteration starts so that the PO has time to chase users and clarify open questions.

I think that having people who are not passionate about their work is a recipe for disaster and there is no easy fix for it. the answer to that problem is very contextual, I don't think you'll find a generic magic trick to turn them around. why are they not passionate about it? what obstacles do they have in delivering high quality?

--
Gojko Adzic
http://gojko.net @gojkoadzic +447765132680

Zico Gupta wrote:
I'm acting as Scrum Master in a team of 7 and I am finding it difficult to induce specification by example in developer's mind. Since all scenarios are not available before development begins, sometimes it results in more number of bugs after the user story is done and released.



what is preventing you from getting to the customers and starting with their examples, then extending that? Can the product owner get realistic examples from customers?

--
Gojko Adzic
http://gojko.net @gojkoadzic +447765132680
I've tried very hard to make the book readable and understandable to developers, testers, analysts and business people alike. there is one chapter on automation that might be a bit too much for non technical people, but that is clearly marked as such and I advise non techies to skip over it as they won't be interested in automation that much. the rest of the book seems to be well received by many different roles.

--
Gojko Adzic
http://gojko.net @gojkoadzic +447765132680
The process I describe as "deriving scope from goals" in the book is very good to manage scope creep. I've used techniques described there to control the scope of large enterprise projects and web gaming platforms alike. the key idea is that you limit the number of business goals a single milestone can achieve (I shoot for one goal at a time, but you might choose differently), and then work towards recognising stakeholders and values that the system needs to provide to achieve that goal. Google for feature injection and effect mapping to see some nice techniques to do that. See my whitepaper about effect maps. If you are based in London or near, you can come and hear me speak about that in about a week, and then some of my clients presenting an experience report. (see the event page on skills matter web site - they will probably film it so if you are not local you will be able to see a video there in about 10 days.

On more traditional projects, the same effect can be achieved with Goal-feature-requirement breakdown that Scott Berkun described in The Art of Project Management (he used it to control scope creep on MS Excel)

--
Gojko Adzic
http://gojko.net @gojkoadzic +447765132680
I don't deal with SOA specifically in the book or any of the we-sold-our-children-to-buy-process-from-gartner architecture methods, so if you are looking for answers on that it's better to read something else. the book has case studies on specification and testing processes in large organisations and multi-site or multi-team groups, but approaches that from the perspective of business focus and collaboration rather than technical architecture. tech architecture is an important concern, but there are many other great books about it.
there are lots of different types of iterative development, from RUP and EVO that have been around for decades to Scrum, XP that have been around for 10 or so years now and Kanban that is just becoming popular. There is no silver bullet or generic way of gathering requirements that works for all that.

I personally hate iteration 0 and think that this is an idea that should have never seen the light of day, but I recognise that in many organisations people have to go through mini-waterfall as a step to an iterative delivery cycle. Many teams I work with work on requirements through a collaborative effort between business users, analysts, testers and developers. This collaboration takes place every iteration or just before the iteration, focused on converting the scope for that particular iteration (eg user stories) into something very concrete that has enough detail for implementation (eg specifications with examples). Milestone scope is typically determined by a separate workshop, involving senior people only, but this is limited to high level scope and not requirements detail. You can see a bit more on different levels of detail in requirements, when they are needed and what are good ways to represent them in the video of my talk at NDC this year.

In Specification by Example I describe the four most common patterns - all team workshops, three amigos, ad-hoc conversations between anyone who has a stake in a story and write+review. these all have different benefits and costs associated with them, so it really depends on what you are trying to achieve and where are the bottlenecks in your team/process.

Scrum by the book (the book being Practices for scaling lean and Agile by Larman and Vodde) suggests that teams should devote 5-10% of an iteration for Product Backlog Refinement. One way I've seen this done is a day every two weeks devoted to PBR, where the entire team gets into a room, spends the first third on breaking down large backlog items, the middle third on analysing and clarifying unclear stories from the backlog and the last third on reprioritisation.

--
Gojko Adzic
http://gojko.net @gojkoadzic +447765132680
at the agile testing exchange 2010, Dan North defined BDD as "A second generation, outside-in, pull based, multiple stakeholder, multiple scale, high automation, agile methodology" (see this great video). So part of BDD has to do with test-first ideas of TDD, but it also has a lot to do with focusing on delivering business value, recognising explicitly who the stakeholders are and what needs to be delivered to them and working outside in (from system outputs to inputs) in order to design the right system. It also focuses a lot on communication, finding the right ubiquitous language etc from domain driven design.

My understanding of FDD is that it organises work according to business feature slices and focuses on a highly iterative delivery process for those features. (I don't claim to be an expert on FDD, so this might be completely wrong). In that view, BDD inherits a lot from FDD but takes that further by emphasising high automation on validation as well as communication with business users and modelling the right system with examples. So, to conclude, BDD is in my view a mix of good ideas from FDD, TDD and also DDD. This is where the "second-generation" part of Dan's definition comes in. It's a collection of ideas that have worked well in different contexts, taken from 10 or so years of experience the community now has with various agile techniques and methods.

--
Gojko Adzic
http://gojko.net @gojkoadzic +447765132680