Skip to main content

Posts

stakeholder value

Willy the CEO slammed down his mobile after another ear bashing from his biggest investor. He took a breath, dialled the newly appointed CTO and explained the situation. “We’re in the last chance saloon, RJ. The board have given us six months to fix what we’re delivering from Engineering. We need to prove our value and fast!” Willy sighed and continued, “They’re pushing me to consider outsourcing everything.” Sitting in his office, RJ took a deep breath and thought about his team’s performance, “My teams are solid. We deliver on time and we deliver high quality, well-tested code but still the stakeholders complain about the product. What’s going wrong?” He reached for the phone and called Colin, the coach. Sitting in RJ’s office some days later, Colin explained to RJ about stakeholder value, “Stakeholders sponsor a product because they believe it will give them benefit or value, if you like. Your teams need to focus on delivering this value to the stakeholders.” “I thought we were doin

non-functional code

...is what I immediately think of when I′m asked to work with ′non-functional requirements.′ If that′s what they want, I am only too willing and definitely more than capable of satisfying the request and have proved this many times in the past. Seriously, though, the way we are presented with these so-called non-functional requirements is amazing, as is the range of them. One of the most common ones is, ″It must be fast!″ Well what does that mean? Programmers are sometimes accused of being pedantic and selfish about what functionality they will let you have from a system but the other side of the coin is the miserly customer, the one who is unable, or refuses, to explain the true extent of the requirement. Fast is a relative term. We need to ask the customer, ″How will we know when it is fast enough?″ In other words, we need to quantify it so we can write a test for it. Tests are how we know that we′ve completed the task and can go on to the next one, or go home. Only when the tests ar

agile pontypridd

Pontypridd must be just about the strangest town in the universe. Apparently, there are houses there with a very strange geometry, so strange that some of them may even be only possile in a multi-dimensional parallel quantum universe. The proof for this is simple. Whenever you meet someone from Pontypridd, mention Tom Jones, the famous singer. You will immediately get a response along the lines of, "I (or my mum/dad grandmother/grandfather) used to live next door to him (or his mum/dad, etc, etc)" This has led many to believe that PontyPridd consists of a couple of many-sided houses belonging to the Jones clan in the middle of the town with all the other domiciles arranged in a circle around them. Obviously, the number of houses next to these necessary to support the many claims of next-dooredness cannot be satified in the three dimensions of normal space, so we may have to imagine the town exists only partly in normal space and partly in that multi-dimensional parallel quant

agile mandate

XYZ were a digital agency and over the years had done many software projects for their customers with varying degrees of success. After learning that many companies were having great success with Agile processes and noticing that even the UK government had decided to adopt those ways of working, the directors had realised the use of these new techniques would improve the performance of their own company. To that end, they had issued a mandate to the project team that by the end of the financial year, they had to have performed at least one Agile project. By this time next year, all projects needed to be Agile. So it was that Colin, our intrepid consultant, found himself in the office of Richard ‘RJ’ Jones, head of XYZ’s Project Office. RJ had contacted Colin so he could get the training and coaching he needed for his team before they started their pilot Agile project. “Tell me,” said Colin opening the conversation, “how big is your team?” RJ though a bit before responding, “We have a t

doggie calculus

Richard Jones was CTO for a large retail company that relied heavily on e-commerce for most of its turnover. Aged 45, he’d been a software developer once and had risen through the ranks before reaching his current position. The responsibility of his position lay heavy on him but he took pride in the ability of his team and worried deeply when they weren’t performing. This was one of those days. Development speed had slowed to a crawl and the defect rate was through the roof. Every time they fixed one defect, they created at least two more. He’d talked to the team and he knew they were doing everything they could but it just wasn’t working. Richard knew they weren’t going to make their delivery date but he also knew he couldn’t talk to the board without a plan of action. A year or so ago, he’d engaged a coach to help the team improve their processes, which had a tremendous effect on the team’s performance and predictability. Was it time to and get the coach back? Fast-forward a couple o

the field of dreams

It was 2005, some years after the dotcom boom and a financial software house asked Colin to help with a project they just couldn’t seem to deliver. Colin sat down at the table with the development team and Henry, the Marketing Director. “Ok,” he said, “You’ve been working on this project for three years but haven’t released any software. Can anyone tell me what the problem is?” Henry spoke up first, “We’ve told them many times what we need but they keep building something totally different.” Mike, the development team lead, shook his head and said, “Yes, but you keep asking for things that can’t be built!” After some similar exchanges, the conversation looked like descending into total chaos so Colin held up his hand to get everybody’s attention. “Can you give me an example?” he asked. “You have to understand we are working in regulated environments,” said Henry, staring angrily at Mike, “this means it’s a massive advantage to us if we can supply a footprint-free application. Anything

the point

Willy, the CEO, was at his desk feeling very satisfied and confident as he read the monthly IT report. Everything was looking good, the report told him the development teams were really performing well and velocity was up yet again. Unfortunately, an email from Jackie, the CFO, disturbed his calm. “I can see the IT teams are busy,” read the email, “but busy doing what? Can we get our changes delivered? They will save us hours of work every month. Why haven’t they been delivered? – Jackie.” To see if he could resolve Jackie’s issues, Willy hosted a meeting between her and RJ, the CTO. “Right, what’s the issue, Jackie?” asked RJ, keen to get the meeting started. “RJ, every month I get reports telling me how many more points your teams have delivered.” Said Jackie, visibly frustrated. “In the latest one, you’re bragging about some of the teams delivering sixty points a sprint for the last three sprints. They may have delivered 180 points but I’ve seen none of my changes. Where’s my stuff?