Pages

Showing posts with label about. Show all posts
Showing posts with label about. Show all posts

Thursday, March 12, 2015

A short story about co location

The post I created yesterday reminded me of this story:

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
Read more »

Tuesday, March 10, 2015

The debate about agile estimating

There has been a lot of noise recently about eliminating estimating for software development projects. Id like to thank Terry Bunio for putting out his thoughts as a rebuttal here. (Note - Terry sits right beside me so weve had a lot of discussion on this topic recently - especially since we thought someone was wrong on the internet #gasp)

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:

Planning Poker is not just an estimating exercise.

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
Read more »

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.

Read more »

Tuesday, February 10, 2015

Lets talk about BTable in Pentaho CDE

Less information.. No example for now from my end.. but want to share what I have now with you on BTable.


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..  :) :) :)





Read more »