Get a PDF of a past bill from T-Mobile

November 25, 2013

This is annoying. On the T-Mobile website I could never get the PDF to display, download, or even get a print of the bill. BAH!

Workaround as below, for you (and for my future reference):

  1. Head to the Past Bills page
  2. Check the page resources and find the JSON response for pastbills (see below)
  3. Take the billStatementId of the bill you want and add it to this URL:

https://beta.my.t-mobile.com/apps/mytmobile/components/content/common/billing/pastbillsPdf?statementID=[INSERT STATEMENT ID HERE]&action=true

For an example of the JSON:

pastbills: “{“pastBills”:[{“fromDate”:”Oct. 19, 2013″,”billStatementId”:”4499720298″,”amountDue”:”95.08″,”toDate”:”Nov. 19, 2013″},{“fromDate”:”Sep. 19, 2013″,”billStatementId”:”4435309747″,”amountDue”:”99.03″,”toDate”:”Oct. 19, 2013″},{“fromDate”:”Aug. 19, 2013″,”billStatementId”:”4367402855″,”amountDue”:”98.02″,”toDate”:”Sep. 19, 2013″},{“fromDate”:”Jul. 19, 2013″,”billStatementId”:”4300649226″,”amountDue”:”103.98″,”toDate”:”Aug. 19, 2013″},{“fromDate”:”Jun. 19,

From all that you get the PDF, which you can then submit to Concur for your expense report. All a bit convoluted, eh? Life.

In Code
 permalink

Must read book: The Phoenix Project

November 19, 2013

Technology reporter Paul Rubens takes a look at IT failures and why they happen, even in big companies, in his article Why IT failures are unlikely to go away. One comment really frustrated me in that post:

Making the software more reliable would undoubtedly be possible, but to do so the developers would have to invest so much more time and money that the price of the product would end up having to be unacceptably high.

Bah!

It is a matter of discipline. If the team knows how to do Acceptance Test Driven Development, and they have the discipline to practice that consistently then they cost will not be significantly higher. The problem arises when a product owner does not see the value of good quality today, and instead pushes that off forever until it is someone else’s problem, or it is too hard to fix without a rewrite.

Technical debt is a thing that can be managed. Companies big and small need to have the discipline to manage their technical debt, and to build quality in. Don’t leave it as an after thought.

Anyways, this post is actually about The Phoenix Project, a great great read about how to address the problems described in Rubens post. Pick it up today and have a read over the weekend, honestly it won’t take more than a day to read.

The Phoenix Project is fun as it is a wonderful story that is infused with the theory and practice behind lean. And no doubt you’ll be able to relate to some of the situations that the team encounters.

Perhaps the folks in Rubens article should pick this up. Quality is fixed, we expect high quality, deliver it!

Go get The Phoenix Project today!

In Agile, DevOps, Recommended Reading
 permalink

Enterprise Product Owner’s Challenge

October 22, 2013

Wow! You must watch this talk from Agile 2013: Enterprise Product Owner’s Challenge: Managing Networks of Backlogs by Alan Goerner of Valtech. This is a talk that I missed while in Nashville and I’m so glad that I went back to watch it. Below are a few nuggets that I took from the talk.

Enterprise Product Owner's Challenge: Managing Networks of Backlogs by Alan Goerner

What is large scale agile?

Complex requirements and a high volume of requirements. As the volume gets larger the product owner and team needs more and more resources, and more and more discipline.

Turns out I’ve been looking for large scale teams along the wrong metric (size). Time to reset that search.

Commitments

Don’t be afraid of them.

Doesn’t mean you’re not agile if you have committed dates.

Customers may want commitments, and they may need to know dates to align with other aspects of their business. There is synchronisation with marketing, manufacturing, etc.

Backlog Hierarchy

The thrust of the talk, leveraging thinking behind SAFe. While you don’t need to have each of these levels they may be useful in a large scale agile implementation (ie, a complex system).

  • Portfolio
  • Release
  • Product
  • Sprint

Each backlog level deals with a specific set of risks. If you don’t have those risks then you won’t need that level of backlog. Further, different kinds of backlogs can be defined by their content.

Another key takeaway – don’t have a backlog for each teams. Add a team field to allow you to filter the one backlog by a team later on. I’m happy to see this aligns with the approach I cover in JIRA for Agile Teams.

Don’t mix team structure with time structure.

Each stakeholder can have their own backlog – this covers multiple sources of demand yet you’ve got to have standards around the level of definition for something to go into that backlog. If the stakeholder doesn’t have the discipline to meet those standards then that stakeholders backlog is not valuable and it will not make the communication visible.

Look, honestly, you’ve got to watch this. I’ve only scratched the surface in my notes above. Great talk, go and watch it for the full deal, now.

In Agile, Product Management, Twitter
 permalink