Implementing 3rd party apps while being Agile

[Dharmesh]

I loved the joint meeting yesterday with AgileKC and KCIIBA. I wish I knew about AgileKC earlier. One of the challenges that we have faced in recent times is being Agile while implementing a 3rd Party application. There is lot of dependency on the support from vendors that can define "done". Some of them are

1] Stories are blocked if the 3rd party app's functionality doesn't work as expected and we have to wait till the vendor fixes the bug.

2] Estimating stories

3] Automated tests around the 3rd party app to ensure our data is consumed and displayed as expected.

What are your experiences? How do you follow Agile when implementing 3rd Party? Are you involved in the RFP process?

Thanks.

[Raghu Kundurthi]

See my answers below:

1] Stories are blocked if the 3rd party app's functionality doesn't work as expected and we have to wait till the vendor fixes the bug.

=> Statement implies the functionality of the 3rd part app was considered as external to story .
=> should include the TPA  functionality asa sub-task in the user story
=> should have the vendor as the 'Assignee' for such TPA functionalities.
=> Daily Huddles should have a vendor rep(not a proxy internal resource for the external vendor)  participate in the huddles to provide status updates.
=> Your company/SCRUM Master/Stakeholder should attach $ value to Vendor TPA functionality acceptance criterion abends/failures.

I think the below two points are addressed by my ex
2] Estimating stories

3] Automated tests around the 3rd party app to ensure our data is consumed and displayed as expected.

And on your point below , I do not see a relation to the Agile/SCRUM discussion thread.

Are you involved in the RFP process?

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To view this discussion on the web visit https://groups.google.com/d/msg/KC_Agile/-/pxIceac8NfAJ.
To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

[James Peckham]

Hi :)

1] Stories are blocked if the 3rd party app's functionality doesn't work as expected and we have to wait till the vendor fixes the bug.

For pure scrum: You can abort the sprint and reform the sprint around other stories

For the pragmatic side of me:you can make stubs or mocks to power the software for a later integration and move on with 'done' not being met yet.

2] Estimating stories

Invite the vendor to your planning poker?

Do a "Spike" first to play with the software.

3] Automated tests around the 3rd party app to ensure our data is consumed and displayed as expected.

Yep. Planning 3rd party vendor support for sprints where you will integrate with them is HUGELY important and you will get tripped up... but isn't that the same with any other project? In my experience it kills us every time but we all attack the problem, solve it or move around it and move on forward with the project. this is why scrum is awesome. Otherwise you'd have a developer sitting there trying everything they can think of for days and days and days sapping away productivity from the project. :) 

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James....@perceptivesoftware.com
www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

Stay connected with us.       

Inspire: The Perceptive Software User Conference
www.perceptivesoftware.com/inspire

NOTICE: If received in error, please destroy the message and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

[Dharmesh]

Thanks for your comments, Raghu. 3rd Party functionality is part of the story, which is why the story is blocked when the functionality does not work.

Not all 3rd Party vendors are available for daily stand-ups. However, we have weekly meetings with them to communicate any blocks from their side. Still that does not unblock the stories till the functionality is fixed. Also, due the nature of our business the vendors are limited that meet our needs. 

The reason I asked whether Agile BA's are involved with the RFP process is to know if there is any value and advantage to identify gaps in the vendor process that will affect the feedback cycle when the sprint is in progress. Eg. Knowing their testing process, process to report bugs and turnaround time for status, etc. I don't see the users asking such questions when they are deciding on the vendor.

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

[Dharmesh]

I agree, James. The challenge with the 3rd Party is their communication process and turnaround time for answers. When the application is built in-house things move much faster.

We do pull stories out of the sprint when it is blocked, but there are times when one bug in the 3rd Party app is blocking future stories. Also, since the 3rd party app is all built, the dependencies exist. How would you account for that?

Good point on including the vendor in our poker game.

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James.Peckham@perceptivesoftware.com

www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

Stay connected with us.       

Inspire: The Perceptive Software User Conference
www.perceptivesoftware.com/inspire

NOTICE: If received in error, please destroy the message and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James.Peckham@perceptivesoftware.com

www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

Stay connected with us.       

Inspire: The Perceptive Software User Conference
www.perceptivesoftware.com/inspire

NOTICE: If received in error, please destroy the message and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James.Peckham@perceptivesoftware.com

www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

[James Peckham]

How would you account for that?

Not sarcastically: When you figure out what works every time, let me know! :) 

To view this discussion on the web visit https://groups.google.com/d/msg/KC_Agile/-/ibjyJk6PGKEJ.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James....@perceptivesoftware.com

www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

[Tom Miller]

In traditional-non-Agile projects the BA is often one of the people who write the RFP after a sufficient round of requirements elicitation.

Tom M.

 

#-#-#-#
"You are entitled to your own opinion but not to your own facts."  NPR's Science Friday 2 March 2012, first hour.
----
"If I have seen a little further it is by standing on the shoulders of Giant" software.
paraphrased from Issac Newton.
-------------------------------------------------------------------------------------------------------------------
Aspiring Business Analyst, Business Consultant and COMPUTER HELP (including IT troubleshooting, website creation/hosting and customizing MS Access-based Applications) and sometime truck driver.  Certifications: CAPM, MCP, MOS & A+, Master Certification in Customer Requirements Analysis, Project Management & Internet Fundamentals from Brainbench.com - http://www.Galensoncaa.com - http://tech.groups.yahoo.com/group/sylvania_smartbook/ - http://www.ChatNFiles.com

---

From: Dharmesh <bar...@gmail.com>
To: KC_A...@googlegroups.com
Cc: kc_a...@googlegroups.com
Sent: Friday, March 16, 2012 1:43 PM
Subject: Re: Implementing 3rd party apps while being Agile

To view this discussion on the web visit https://groups.google.com/d/msg/KC_Agile/-/bzbeZEI8Pt8J.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.

[Mark Randolph]

Regarding late 3rd party contributions, I learned this trick from a guy at CERNER.

 

Create a mock object. This is a stub application/service/object that conforms to the specification of the 3rd party API, but only mimics its behavior. For example, assume the missing component processes credit card transactions, but is late, late, late. The mock object would take valid and invalid credit card numbers and then pretend it knows what to do with them. Give it valid number ABC, and it returns a fake transaction number. Give a bad number, EFG, and it returns "refused." The stub only needs to know that if it sees "ABC" return a valid transaction code, and if it sees "EFG" return "refused," and if it sees anything else throw an exception.

 

Stubs are cheap and fast to create and allow significant development to proceed in the face of delayed 3rd parties. Of course, you need some sort of an API specification, but even an incomplete or unstable spec can get you started. You also might think stubs are "throw away" code, but they are not. You can build the things to respond to "edge cases" that are difficult or impossible to induce in the field.

 

If you see objections to using stubs (and they are myriad), please toss them my way so I can practice fielding them.

 

Mark Randolph

A.K.A. the "Bald Ego"

 

 

-----Original Message-----
From: kc_a...@googlegroups.com [mailto:kc_a...@googlegroups.com]On Behalf Of Dharmesh
Sent: Friday, March 16, 2012 12:48 PM
To: KC_A...@googlegroups.com
Cc: kc_a...@googlegroups.com
Subject: Re: Implementing 3rd party apps while being Agile

To view this discussion on the web visit https://groups.google.com/d/msg/KC_Agile/-/ibjyJk6PGKEJ.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.

[James Peckham]

Yea! Stubs are great to put in your continuous integration build because they run faster than a third party lib end to end and they isolate errors better

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James....@perceptivesoftware.com

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James....@perceptivesoftware.com

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James....@perceptivesoftware.com

www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

Stay connected with us.       

Inspire: The Perceptive Software User Conference
www.perceptivesoftware.com/inspire

NOTICE: If received in error, please destroy the message and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To view this discussion on the web visit https://groups.google.com/d/msg/KC_Agile/-/ibjyJk6PGKEJ.
To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com.

[Jeremy Mason]

I agreee 100% with Mark said about building stubs/mocks around 3rd party applications in order to minimize the impact they can have on meeting sprint goals.

I just wanted to add that this method of designing software is not unique to integration with 3rd party applications.  Building specifications around the orthogonal parts of your application (whether they are formal specifications, or more commonly a documented interface in code) will help in several areas:

1. Software is easier to test because you can inject "mocks" to test weird edge cases that are difficult to reproduce, such as what happens if a client loses connectivity, or the database goes offline.
2. Work can be distributed among multiple developers, and stubs can be used in place of real implementations, as long as they agree on the interfaces.
3. Maintenance hopefully becomes easier because the product ends up being broken down into smaller, loosely-coupled objects with fewer responsibilities, versus a tightly-coupled monolithic structure.
   

Jeremy

--

"Choose a job you love, and you will never have to work a day in your life." - Confucius

[Barton Stanley]

One objection I can see to stubs is that by using them we violate the idea of deliver a "slice" to the end customer.  By delivering a slice, you discourage developers from developing a database layer and getting that to be perfect before you build on top of it.

I've been struggling with this a bit myself because in my environment, I depend on non-Agile teams to deliver back-end functionality and their schedules don't necessarily mesh with ours.  If we don't stub things out progress will get stalled so we pretty much *have* to stub things out.

I'm wondering how others handle stories for this with regard to acceptance criteria.  If you stick strictly to the "slice" model then you have to say that the story is not done until the stubs are replaced with the "real" code.  What I don't like about this is that my stories could stay open for a couple of iterations, which just seems silly.  After all, I can create a release with the stubs and have the customer look at it to see if the UX matches his expectations.  If not, we can fix now rather than waiting until the back end is done.  To address this, I've created two stories, one for the stub and one for the real thing:

1) customer can purchase subscription so that he can access the service (stubbed out)

2) customer can purchase subscription so that he can access the service (with back-end)

So I am curious, how do others deal with this?

Barton

---

From: Mark Randolph <markra...@everestkc.net>
To: kc_a...@googlegroups.com
Sent: Fri, March 16, 2012 10:32:24 PM
Subject: RE: Implementing 3rd party apps while being Agile

To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+unsubscribe@ googlegroups.com.
For more options, visit this group at http://groups.google.com/ group/KC_Agile?hl=en.

--
Raghu Kundurthi

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.

To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+unsubscribe@ googlegroups.com.
For more options, visit this group at http://groups.google.com/ group/KC_Agile?hl=en.

To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+unsubscribe@ googlegroups.com.
For more options, visit this group at http://groups.google.com/ group/KC_Agile?hl=en.

--
Raghu Kundurthi

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.

To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+unsubscribe@ googlegroups.com.
For more options, visit this group at http://groups.google.com/ group/KC_Agile?hl=en.

--

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James.Peckham@ perceptivesoftware.com
www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

Stay connected with us.       

Inspire: The Perceptive Software User Conference
www.perceptivesoftware.com/ inspire

NOTICE: If received in error, please destroy the message and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To view this discussion on the web visit https://groups.google.com/d/msg/KC_Agile/-/ibjyJk6PGKEJ.
To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com.

[Gregory N. Smith]

We make heavy use of mocks/stubs in Thoughtworks.  My preference is to minimize the number of stories and maximize the number of states they transition through.  1) to manage what your *stories* are doing instead of even offering the temptation to manage what your *people* are doing.  And 2) to create explicit visibility into where the bottlenecks/flowjams are.  For example we often see 3 states, ‘not started’, ‘in progress’, and ‘done’.  With a role based decomposition of “stories” bloating the tracking system which are constituent tasks really.  What we like to do, and I think it will work nicely here, is to create quite a few more states.  A common mix is “not started”, “blocked”, “in analysis”, “ready for dev”, “in development”, “ready for qa”, “in qa”, “ready for showcase” and finally “done”.  In this layout you remain with fewer and less redundant stories and the real job of team management and continuous improvement is managing the queue length in each state and setting limits to how many things are allowed in each state at a time.  There’s no point in doing more upstream work if one later state is sitting full of an untouched inventory of work.  What I’d recommend is perhaps another state, maybe between “in dev” and “ready for qa”, something like “3^rd party integration”.  This will give you pretty concrete visualizations of how long the “3^rd party integration” queue is, and optionally do some fancy math and show how many $/turnarounds/happy customers are on the other end of that queue.  This can be used as a nice tool to get sr. management or leadership to understand that all agile teams’ performance is hampered (with hampered hopefully expressed as a $ value per sprint/release/quarter) and thus build objective demand for these other teams to pick up their cadences too.  I was careful to say ‘picked up cadence’, not ‘adopt agile’ because Lean or Kanban may very well be the right answer for a shared team that lots of others depend on.  A possible side effect is that the agile team has very little ‘done’ work to demonstrate BUT in an environment which makes the reason for this perfectly clear.  Splitting into a “ba story” and a “dev story” and a “qa story” is functionally equivalent to the “with mocks” and “without mocks” stories in that both try to grant partial credit in allowing teams to celebrate doing a portion of a story that isn’t really done.  I would not bifurcate the stories in this way.  This is one of many behaviors I call putting bandaids on broken legs.  I completely understand how you got there but this type of patching what is essentially an organizational or partnership broken-leg with a team bandaid won’t help raise visibility of and get attention focused on the root issue.

 

$.02

What does everyone think?

-G

Barton

Inspire: The Perceptive Software User Conference
www.perceptivesoftware.com/ inspire

NOTICE: If received in error, please destroy the message and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

 

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To view this discussion on the web visit https://groups.google.com/d/msg/KC_Agile/-/ibjyJk6PGKEJ.
To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

[James Peckham]

I am very curious, in practice, how does something like this play out usually?

I have personally seen a lot of learning and planning coming from reading the spec and building a stub... in fact, when we've done it we have actually uncovered bugs and quality issues within the vendor's product and positively impacted the whole relationship and architecture. I have also seen testing able to create test automation sooner with a stub. I generally advocate programming from the front to the back, acceptance test driven development, with fake/stubs at each layer all the way down so that we can have something running and 'testable' on the first day. We were also able to validate all of 'our code' isolated from 'their code'. Knowing it's 'their issue' is HUGE in supporting/maintenance. I'd say most of the time if you follow a vendor's spec you will have very little integration troubles to solve especially if they're a reputable vendor with a good spec. We did this with a credit card ISO at commerce bank and it worked flawlessly. I also did it numerous times with our middleware department also. 

I want to add here, i am NOT advocating stubbed code as "Done" but simply as a way to move forward for the team until work can be finished by the vendor. It's not a clean/pure agile way of doing work but thinking about flow we have to look at the vendor as part of the value stream and simply roadblocking ourselves until they deliver something is the main thing I would want to avoid because as soon as they do deliver something I would want integration to happen fast.

Thanks,

James....@perceptivesoftware.com

www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

Stay connected with us.       

[Dharmesh]

We have used stubs to mock the data tables in a few cases with mixed success. Our IT is a proponent of mocks/stubs but users are not. In fact, recently we were trying to get user buy in on using a mock web service to test some of our third party stubs. As long as you educate the users that the integration will happen and will be tested in future I don't see an issue in using mocks/stubs.

Dharmesh

[Dharmesh]

Gregory, this is a very interesting thought. It looks a bit overdoing at first but after putting some thought I kinda like it with some restrictions. We use the 'not started', 'in progress', and 'done'. 

A common mix is “not started”, “blocked”, “in analysis”, “ready for dev”, “in development”, “ready for qa”, “in qa”, “ready for showcase” and finally “done”.  

Is this your common practice on most of your projects? I see the extra benefit for the management for bottleneck analysis but does it provide value to the team?

Thanks for sharing.

Barton

.
To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at

http://groups.google.com/group/KC_Agile?hl=en.

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com

.
To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at

http://groups.google.com/group/KC_Agile?hl=en.

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com

.
To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.

For more options, visit this group at

http://groups.google.com/group/KC_Agile?hl=en.

[Troy Tuttle]

Jumping in with a couple of comments, but don't want to get in the way of Gregory's answer.

First, I agree with James, Mark, and others on the value of stubs and mocks to facilitate testing at system and logical boundaries. Even without this 3rd party integration, they are a good practice, IMO.

The multiple work states is an example of a Kanban approach. The idea being, that there may be a need to better visualize your work than just showing "Todo, Doing, Done" work states. The key isn't to model something after Gregory's example, but to find a way to better visualize your team's work. It may look completely different.  

But even if your team decides to use mocks, you still have a process problem that technology can't solve. What I think Gregory is recommending (and I support) is highlighting your process dysfunction through better visualization. I would add one more component to that, measurements. Dharmesh, in your first email, you mentioned the need to estimate these stories that involve 3rd party integration. Rather than asking people to predict the unpredictable, try measuring the cycle time on all your stories and show the difference between regular stories and those requiring 3rd party integration. I may help you plan better, and could prompt Kaizen conversations about how to lower those 3rd party cycle times.  

A couple of resources on Kanban learning:

http://limitedwipsociety.org

http://www.leankanbanuniversity.com/

Hope that is helpful.

Troy Tuttle 

http://twitter.com/troytuttle

http://blog.troytuttle.com

[Raghu Kundurthi]

Mocks & Stubs use mandates the existence and practice of the following mature baselines:

1. A  mature MDM in place.

2. UAT/QA teams involvement in articulating , approving the mocks/stubs.

On Extreme Programming:

- Again mandates that the pair programming team work to optimize the codebase artifacts while driving the EP effort.


-Raghu

To view this discussion on the web visit https://groups.google.com/d/msg/KC_Agile/-/VQanIKT0rTcJ.

To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

[Gregory N. Smith]

I think I just outsourced my response J  +1 on all points.  This is absolutely modeled after a Kanban approach.  As to whether it’s a standard or default approach I have to say “kind of”.  The specific states and number of them; no, the idea of molding a more explicit set of states specifically aimed at raising organizational or team issues into visibility, yes.  New joiners at Thoughtworks often are disappointed thinking they will come in and learn “the Thoughtworks way” only to find out that there really isn’t one.  One of my favorite sayings is “It’s a spice rack not a cookbook, you still have to learn how to cook, what you are allergic to, and what your customers think is tasty!”

 

The thing I started reacting to was having a “mocks/stubs ON” and a “mocks/stubs OFF” variant of each story which I do not think I’d support in most situations.  It seems dangerously close to a “partial credit” model or at least a model that may tempt people towards partial credit over time.  Rather, it feels like those are more waypoints on a definition of done than explicit stories to me.  Even with just 3 states we’ll see a similar dynamic as with 5,6 or 7 states (stuck stories) , I just tend to favor explicitly identifying the “problem child” stories in more objective way since it usually helps me build a case for organizational change up to and including the  improved alignment of or selection of different partners/vendors.  The last time I used this very effectively it led to the decision after 3 sprints not to use Oracle finance for a particular project at a very heavy Oracle shop.  Another example was using this explicit visibility to get a client to invest in creating their own unit testing framework for Siebel configuration script.

 

-G

 

 

 

 

From: kc_a...@googlegroups.com [mailto:kc_a...@googlegroups.com] On Behalf Of Troy Tuttle
Sent: Tuesday, March 20, 2012 11:14 AM
To: kc_a...@googlegroups.com
Subject: Re: Implementing 3rd party apps while being Agile

 

Jumping in with a couple of comments, but don't want to get in the way of Gregory's answer.

--

You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com.

To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.

[Barton Stanley]

Thanks to everyone for your feedback on a stubs on/stubs off approach to stories.  We are an isolated agile island within the organization and so it is very helpful to hear from those with more experience.  I had tried this on one particularly troublesome story, all the rest adhere to the idea of delivering a "slice" of functionality.

From what I can tell, the tally is unanimously against the stubs on/stubs off approach.  The comments I find most helpful are those centering around highlighting dysfunction and I can see that taking the stub on/stubs off approach is likely to enable the dysfunction rather than fix it.  I think in my environment I can do this most effectively by flagging the story as an impediment and letting it escalate.

Thanks again for the feedback.  I hope at some point I can return the favor.  In the meantime, however, I may be back with other questions! :)

Barton

---

From: Gregory N. Smith <gns...@thoughtworks.com>
To: kc_a...@googlegroups.com
Sent: Tue, March 20, 2012 12:28:37 PM
Subject: RE: Implementing 3rd party apps while being Agile

[Mark Randolph]

Yes, stubs on/off BAD for all the reasons articulated. Stubs on/off GOOD as an alternative to being stuck in the oobleck.

 

Mark Randolph

[Dharmesh]

Troy, thanks for elaborating on the multiple states approach. I felt there was Kanban somewhere in there. Also, you clarified whether Gregory's example was solving the problem or aiding better visualization. It surely looked like it was helping to better visualize but wanted to make sure I am not missing the point.

We may have to work on a mock project to get acquainted with the use of mocks :)

This discussion has been very helpful. Thanks to all who chipped in.

To unsubscribe from this group, send email to KC_Agile+unsubscribe@googlegroups.com.