Thursday, March 12, 2015
A short story about co location
A team I was working on was asked to sit together in a rather cramped area. Five of us (two developers, one application architect, one tester, one business analyst) were asked to share a very small area about the size of a typical office. The business analyst had desk space equivalent to the size of a typical end table; there were monitors perched precariously above us on small shelves; we shared one phone; and the limited wall space we had was covered with our visible boards and stickies. Fun!
As we reflected on our space at the end of the project, this comment was made from one of the developers: "On the bright side, I dont think I looked at the requirements document once. I just turned to the business analyst beside me and asked her what needed to be done!" Co-location for the win.
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" - Agile Manifesto
Tuesday, March 10, 2015
The debate about agile estimating
To summarize my understanding of the issue:
- Estimating is a waste because we are going to be wrong anways.
- Estimating is a waste because we could be delivering value instead.
While these two statements have caused a lot of debate, there is a ring of truth in both of them. So, if we are going to do some form of estimating, can it a) help us be more truthful about our estimates and b) increase our ability to deliver value? This is the beauty of relative estimating through planning poker - and here is my main point, bolded and centered for emphasis:
Yes, one of the main outputs of planning poker are points estimates. But it has other results that address the concerns above.
a) It allows us to be more truthful about our estimates:
- Relative estimates in concert with user stories and managing to done enable you to track the velocity of your project so you can predict actuals sooner (i.e. tell the truth about your estimates as soon as possible). In turn, this allows us to make better choices about the future of the project (like helping the marketers decide when to launch a campaign about the project), and measure the results of our continuous improvement experiments.
b) It increases our ability to deliver value:
- Planning Poker is also a scope discovery tool (see my thoughts here). After a planning poker session our team will have a much better understanding of what the client wants and expects - therefore enabling us to deliver it to them sooner and with less misunderstanding and frustration.
- Planning Poker creates team ownership of your estimates - including joint ownership with the client.
- Planning Poker allows your client and users to have a much better understanding of what it takes to build what they are asking for and informs their choices when prioritizing.
In closing, so far all of our clients have required us to create estimates and well continue to do that. But, we like to start with points through planning poker because of the value added as above and then take a few stories and extrapolate to hours. After that, we ignore the hours and focus on velocity. This feels like a balanced and professional approach.
**************
Some additional reading on this issue if you choose. The last one contains some ideas that I strongly disagree with and that Terry responded to in the post above (despite his affection for TargetProcess in general).
- http://blog.mountaingoatsoftware.com/how-do-story-points-relate-to-hours
- http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html
- http://www.sdtimes.com/link/35401
- http://www.targetprocess.com/blog/2011/04/5-reasons-why-you-should-stop-estimating-user-stories.html
Come Learn About Apps Script in Washington DC
Editors note: This has been cross-posted from the Google Code blog -- Jan Kleinert
Google Apps Script is a JavaScript cloud scripting language that provides easy ways to automate tasks across Google products and third party services. If you want to learn more about Google Apps Script, collaborate with other developers, and meet the Apps Script team, here’s your chance! We will be holding an Apps Script hackathon in Washington, DC on Wednesday, March 7 from 2pm - 8pm.
After we cover the basics of Apps Script, you can code along with us as we build a complete script, or you can bring your own ideas and get some help and guidance from the team. There will be food, power, and Apps Script experts available to help throughout the day. Just bring your laptop, ideas, enthusiasm, and basic knowledge of JavaScript. Check out out the details of the event and be sure to RSVP to let us know you’re coming.
![]() | Jan Kleinert profile | twitter Jan is a Developer Programs Engineer based in NYC, focusing on helping developers get the most out of Google Apps Script. Prior to Apps Script, she worked on Commerce, helping merchants integrate with Google Checkout and on Chrome, helping developers build great web apps. |
Tuesday, February 10, 2015
Lets talk about BTable in Pentaho CDE
Bug link :
http://forums.pentaho.com/showthread.php?154497-BTable-installation-issue-PentahoMarketPlace
Solution link :
http://www.biztech.it/btable/
Will update this post once I work out with a simple example.. :) :) :)


