Articles for category: Delivery

February 14, 2017

Greg Thomas

One Size Does Not Fit All

Have you ever bought a shirt that fit you and given it to someone else who was either smaller or larger than you? Didn’t fit, did it? What about following a development pattern that lays out how to build user interfaces on the web while you are building a desktop application? Probably didn’t fit either, all good ideas, all software, but the fit isn’t there. What about using a new software methodology? Agile, Scrum, Waterfall, Lake, River (the last 2 are made-up)… Did they fit the first time? Do they apply to your business? Do they fit within your culture? There are

January 24, 2017

Greg Thomas

The Rebuild or the Rebuy

When we rebuild something, we take the problem, deconstruct it to it’s bare bones and fix it with what we have. When we rebuy something, we identify the problem, build some requirements and hope the purchase of a solution will fix our problem. Rebuilding involves understanding the problem from beginning to end and investing yourself into design, development and deployment of the solution. Rebuying involves less effort being spent on development and hopefully more on the actual implementation. Good developers know that when they rebuild, they are learning, developing and growing. Great developers know when they need to make the hard

January 10, 2017

Greg Thomas

Why are they standing up?

Have you ever watched the final round of a Texas Hold’em Tournament when it’s down to 2 people playing Head to Head. Ever notice when they go All-In how they stand-up and go hang out by their family and friends in the stands, watching the cards from afar. At that point – the game is completely out of their hands. Now notice that when they win, the winner’s family and friends go crazy, cheering and clapping for them? At first glance you’d think they are cheering for the hand (largely out of their hands at that point) but they’re not,

The Airplane Test

Imagine an airplane perfectly taking off, flying through the air, getting to cruising altitude, descending and making a perfect landing. Now take your current team – all facets – Business Analysts, Product Managers, Developers, Systems Integrators, Quality Assurance, Support, Trial Specialists, etc, etc – and imagine them all on one team, standing in an empty hangar. Now imagine what plane they are going to build. Are they able to create the plane you need in the initial scenario? If not, what do you need to do to get them there. PS – I wrote about this before – but it’s

Owning the Problem towards the Solution

A 5-minute owning up to the problem and what you should have done is much more productive than a 35-minute debate on what you did do in an attempt to prevent what went wrong. The former gets the ball rolling towards a solution, both parties focussed on moving forward, together. The latter stalls the solution process, strengthening walls, instead of breaking them down.