AGILE IN ACTION

Thursday, December 20, 2007

Entropy always wins

Posted by Simon Baker
Read more... Comments: 1

Sunday, December 16, 2007

Building trust

Posted by Simon Baker
Tags: trust
A bit of trust goes a long way . (Via Pascal Van Cauwenberghe ) David Anderson gives us a few tips on building trust: Be humble and respect the other Vulnerability disarms Apologise for poor results; take responsibility, even if you weren't involved in the delivery of the poor results; promise better; deliver Keep delivering, regularly, predictably Deliver daily on your personal commitments; deliver daily or weekly on team commitments Demonstrate competence; rehearse and practice for perfect delivery Be transparent Encourage learning from failure Get rid of command and control Build up a reputation Define clear values and principles; let them guide decision making

Follow me and let's figure it out together

Posted by Simon Baker
Via InfoQ . Mary Poppendieck talks about the role of leadership in software development at Agile2007 . Here's the handout to accompany the video. What I found particularly interesting was the history lesson: 1900s: Frederick Winslow Taylor and his Scientific Management and his contemporary Charles R Allen with his on-the-job training. 1940s: Training Within Industry . 1980s: W Edwards Deming and his System of Profound Knowledge . 1980s - Present day: Toyota Production System . Here's a quote Mary used that I like:
Read more... Comments: 1

Saturday, December 15, 2007

At last an organisation willing to try

Posted by Simon Baker
We're currently working at a FTSE100 Corporation and, 9 weeks in, we've entertained a few senior executives and executive board members. They've dropped by for a walk through our informative workspace with a running explanation of how we're working, culminating in a demonstration of the working code so far. When the CTO visited he threw away protocol and sat in the bullpen to engage in some simulated pair-programming . When the COO visited he asked many insightful questions and I think he was pleased to hear about our Product Stream concept that was allowing us to work as one with the Business. When the CFO and the CEO visited, the CEO was very interested in our application of Lean thinking. The CFO really liked our big visible charts showing how we're spending our 7-figure budget (burn rate, cumulative spend, return on investment per iteration, projected total spend, categorised expenditure, etc), but his most telling remark followed our iteration showcase (where story owners demonstrate the functionality delivered in the iteration and the team fields questions from the audience). He said:
Read more... Comments: 1

Looping the loop

Posted by Simon Baker
All teams have blips. I sensed growing frustration in the team over the last few iterations - sniping, bickering, moaning, negative comments. Morale was starting to be affected. When the team norms were breaking down and a lack of respect started to emerge I decided to intervene and focus the next retrospective on getting to the root of the problem.
Read more...

Retrospective using Appreciative Inquiry

Posted by Simon Baker
The iteration after looping the loop has been the best yet. Everyone enjoyed it immensely. The team were buzzing and the Product Owner, Product Sponsor and Customer were ecstatic. I really wanted to tap into the positivity and leverage the energy to consolidate our gains in teamwork so I decided to facilitate an appreciative retrospective.
Read more...

Who'd believe it?

Posted by Simon Baker
We're 9 weeks into our project. 1 week in and we had built the rudiments of a working portal. When we were 2 weeks in we asked our Product Sponsor if we could put an early version of the portal (and the Publisher system we're building to go with it) live before Christmas. If I'm honest I'm not sure he believed we could do it but he liked the idea and gave us the go ahead. We've been building out the functionality iteratively every week since then. On Thursday evening we put an early version of the portal live and we celebrated with pizza. During the day there was lots of fun and frolics. Judging by some of the looks we were getting, I don't think people in the company had seen people in the process of going live be so relaxed, let alone have fun. Now it's done, the Product Sponsor is excited and can't decide whether to publicise the portal. A nice dilemma to have.
Read more... Comments: 1

Friday, December 14, 2007

Become part of the status quo or leave?

Posted by Simon Baker
If you can't work with the status quo of a company should you get out rather than try to change it? The status quo - the existing state of affairs - is a natural phenomenon. I think the problems start when the need is felt to protect and defend the status quo because this tells me that continuous improvement has stopped. Continuous improvement is about making successive small changes forever, based on application, inspection and adaptation, that bring about progressive improvements. In my experience, in the absence of continuous improvement the status quo stagnates. When you care about the company (and you should care) you want to try to help it improve so that it can become more successful. Why wouldn't a company want to get better at what it does? But ultimately change has to come from within and if the company and its people are happy with the status quo and you're not, I think they're best left alone and you're better off out of it. It's a tough call but what does your conscience say?
Comments: 1

Wednesday, December 12, 2007

Who am I to question the value of low quality software to the customer?

Posted by Simon Baker
In our XP Day session , Chris Pitts was the table host asking are organizations valuing the right things? Somebody challenged him with: Who are you to question the value of bug-ridden software to the customer? For what it's worth, here's what I think ... In undertaking any work for a customer, it's important to understand what the customer values and why. Developers have spent a long time with their heads buried in the sand. Paraphrasing Kent Beck: It's not enough to write great software, you need to be aware, be accountable, and you need business acumen. As someone hired to create the software it would be remiss of me not to ask why the customer values low quality software. I reckon it's fair to say that, in the majority of cases, the Business doesn't truly understand the (cost of the) consequences of low quality software down the line. And as a technical person, I might not fully understand everything about the business, but I do understand the concept of cost, return on investment, and I have a good idea of the (cost to the Business of the) consequences of low quality software. It's a myth in the IT industry that quality costs more. Ok it's likely to cost more in the short term, but baking quality in from the start eventually boosts productivity and over the medium to long term the business gets more, with high quality, for less. Only seeing the short-term focuses on the fraction of time software spends in development and disregards the majority of time software spends in post-production maintenance and enhancement. We have a responsibility to work with the Business to help them understand the inherent value of quality and the benefits it brings. In the majority of cases, the software is a corporate asset. In the context of client-vendor relationships, Deming has written extensively on the trend of awarding business based solely on price . Deming said driving down the price without regard to quality will drive good vendors out of business . I would also argue that a lack of regard for quality by the Business is making craftsmen, people who recognize the value of quality, a dying breed. In the IT industry we're seeing vendors support slashed prices by cutting quality. They make their money back by charging extortionate sums for change requests. (This is why the argument between client and vendor about whether something is a defect or an enhancement or a new feature has become so prevalent). Vendors won't admit to developing poor quality software but they're in business to make money so they will argue that something is not a defect. This modus operandi is embodied within many business models. I don't agree with it but I can certainly understand why they do it. They're driven to it by the Business not understanding the value of quality. Who am I to question the value of low quality software to the customer? I'm someone who cares about business as much as the Business does and I'm someone who cares about software .
Comments: 5

Monday, December 3, 2007

Standard work is only the best way so far

Posted by Simon Baker
The concoction of Extreme Programming, Scrum and Lean thinking I'm using is the best way I've found to do software product development so far . I'm applying it, I'm inspecting the results, I'm adapting it to continuously improve it, and I'm learning ... all the time. It's Standard Work that is simply a baseline for doing further kaizen . There are other best ways too that relate directly to other peoples' experiences.