www.thought-bubble.co.uk

This post does not need to be long.  If I can make a spaghetti carbonara in half an hour, it would be a mistake to think that I could make another and another and another each in half an hour one after the other.  Once I have made my spaghetti carbonara, I need to wash up otherwise my sink will fill up and I will run out of cooking utensils. I need to clean the worktop surfaces otherwise I will run out of worktop space.  If I neglect the clean-up part of the job I will very soon be hindered in the speed with which I can make another meal, the washing will build up and I will need to stop and attend to a mountain of cleaning.

Software and tech debt work in the same way.

This post is from agileconference.org by Manav Mehan and Jonathan Elliott.

Two of the major market forces in last decade with the greatest impact on Organisations has been the emergence of the ‘Digital Enterprise’ and ‘Organisational Agility’.  If used smartly, both can give significant competitive advantage to the Business.

Simply put, a Digital enterprise is an organization that uses technology as a competitive advantage in its internal and external operations. On the other hand Organisational Agility means the enterprise has made the journey from ‘Doing Agile’ to ‘Being Agile’ across the horizontal business functions and vertical organisational structure.

TCS has good experience helping organisations embrace a Digital enterprise strategy using an holistic framework to guide companies through the digital universe and enable them to maximize digital opportunities in a coordinated, integrated approach.  TCS believes a combination of pervasive networking, the explosion of big data, the availability of advanced analytics and social media, and the fact that mobile technology will become the businesses’ new face of engagement means that, in the very near future, “digital” and “business” will be synonymous. Using Big data, cloud computing, social business, and mobility as key transformation tools, TCS effectively creates the Digital ecosystem to drive the ROI across Technology & Business.

Click here to see the full post.

This post is from gojko.net by Gojko Adzik.

I got a question from one of the blog readers on how I would describe a spec with examples for a user-interface specific user story, such as “As a user, I want to register in order to log in”. The reader challenged the value of doing a Cucumber test for the registration, because it’s obvious and mostly UI-heavy. First of all, there is nothing obvious about that story. In fact, that is the problem! I wouldn’t even try to describe the spec for it, because that would just be continuing a garbage-in-garbage-out queue. A good user story is a necessary input for a spec workshop. A good user story is one that helps the delivery team reach a shared understanding on what it is about, and that helps the team discuss the needs with their business stakeholders. “As a user, I want to register …” fails miserably there, because it is a lie.

The lie starts with the whole premise. “As a user, I want to register”…. No I don’t. As a user I don’t want to give my private information to another site, have to argue with some arbitrary fascist filter about which combination of letters and numbers is strong enough, try to guess what’s written on some random distorted image, and then have to remember another set of fake privacy answers. That sentence might be in a user story format, but it’s far far from a user story. It’s grammatically correct, but completely false, just like saying “As a citizen of Greece I want to pay my tax so that the EU stops giving us free money”.

Click here to see the full post.

This post is from leanagiletraining.com by Joe Little.

Imagine that you have gotten some interest in Agile. Perhaps you read a book, and talked with a friend who is doing it at his firm.

And then you take a Scrum course.

Now what do you do?

Let’s take a middle of the road case, where you have a software development group of 80 or so, and business people for another 20 people. You are one of the 80.  You’ve come back to the office on Friday morning. You want to do something with Scrum, but you are unclear where to start.

Click here to see the full post.

This post is from leadingagile.com by Dennis Stevens.

Most of the organizations we engage with have more work to do than they can possibly get done. So, developers are writing code as fast as they can to get done trying to maximize their capacity. Typically, we see developers running way ahead of testing. Often, testing is still working on the prior release while development is running off on the next release – and testing just can’t ever catch up. This inventory of untested code shows up as long lists of defects, lots of code branches, untestable features, and products that can’t be integrated or regression tested until just before the next release. This vicious cycle of long bug lists, painful regression testing, and production defects colliding with the next release continues to grow.

The goal is not to write code faster. The goal is to produce valuable, working, testing, remediated code faster. The most expensive thing developers can do is write code that doesn’t produce something needed by anyone (product, learning, etc). The second most expensive thing developers can do is write code that can’t be tested right away. Recently, LeadingAgile’s Derek Huether wrote about Getting Teams to Deliver Predictably. He shows how having more work in the queue than can be performed slows down throughput. Pretty quickly, everything gets congested and things back up, building up latency and uncertainty in flow.

Click here to see the full post.

This post is from leadingagile.com by Dennis Stevens.

Agile versus Waterfall

These words have become completely overloaded when discussing product development. Lots of conversations about helping organizations improve their product development processes go sideways based on individual perspectives about the meaning of Waterfall and Agile. At this point these words don’t provide a distinction that is helpful when we are trying to figure out how to build products in organizations. It’s a red-herring contradiction. When I hear someone say “we need to do that Waterfall” or “that wouldn’t work in Agile” or “we can use Agile for that project” then I want to stop and ask “what does Agile mean to you?” or “what do you mean by Waterfall?”

I want to break down this debate into a clearer discussion around specific characteristics; Type of Effort, Upfront Planning, Sequencing and Feedback, and Composition of Teams. Then talk about how understanding these characteristics helps us improve the ability to be predictable and achieve the fastest time to ROI.

Click here to see the full post.

This post is from kenschwaber.wordpress.com by Ken Schwaber.

The boys from RUP (Rational Unified Process) are back. Building on the profound failure of RUP, they are now pushing the Scaled Agile Framework (e) as a simple, one-size fits all approach to the agile organization. They have made their approach even more complicated by partnering with Rally, a tools vendor. Consultants are available to customize it for you, also just like RUP.

They are touting their processes and tools this week at Agile 2013 in Nashville. They would be at the RUP conference, but there are none. They would be at a waterfall conference, but they are no longer. So they are at our conference. Strange, but they had nowhere else to go. Try to be polite.

Click here to see the full post.