Entropy always wins
Your world is changing faster than you'll ever be able to keep up with, and you can view that fact from 2 different perspectives:- I believe I can control my world, and through an aggressive campaign of task management, personal goals, and can do attitude, I will succeed in doing the impossible. Go me!
or
- I know there is no controlling the world, but I will fluidly surf the entropy by constantly changing myself.
Surfing entropy takes confidence; this is a personal confidence you earn by constantly adapting yourself to the impossible.
Links to this post
Follow me and let's figure it out together
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:
Here's a quote Mary used that I like:
We get brilliant results from average people managing brilliant processes. Our competitors get average results from brilliant people working around broken processes.
-
Fujio Cho, Chairman of Toyota Motor Corporation
Tags:
lean,
leadership
Links to this post
Building trust
A bit of trust goes a long way.
(Via
Pascal Van Cauwenberghe) David Anderson gives us a few tips on building trust:
- Trust begets 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
Tags:
trust
Links to this post
Who'd believe it?
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.
Links to this post
Retrospective using Appreciative Inquiry
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.
I introduced the retrospective by stating the following affirmative goal:
During this retrospective, we'll find ways to amplify our strengths in process and teamwork.
Here's the agenda:
1. Prime Directive2. Check-in (5 min)
To get each person talking, ask every person to check-in by showing their appreciation for someone else on the team. They should say something like:
I would like to thank so and so for doing x.
3. Brainstorming (5 min)Gather data by asking the team to brainstorm enjoyable events, team strengths, and successes. Have them write each one on a colour-coded post-it note.
4. Futurespective brainstorming (10 min)To begin generating insights ask the team the following question:
Imagine we could time travel to the end of the next iteration/release. When we arrive there and converse with our future selves, we hear that it was the most productive, most satisfying effort we've ever worked on. What do you see and hear in that future time?
Have them write on a different colour post-it notes.
5. Affinity mapping (15 min)Ask the team to group related post-it notes and assign each group a name.
6. Dot voting (5 min)
Tell the team to examine the groups again and to think about the things they identified in the future, and then ask:
Building on our successes to date and given our team strengths what do we really want to sustain?
When they've taken a minute to think ask them to
dot-vote to identify what (group) they want to sustain going forward.
7. Identify the take-away actions (20 min)Now the team needs to decide what to do. Ask the question:
What actions should we take to amplify our strengths in process and teamwork that will help us build towards the successes we have foreseen?
Facilitate a discussion to identify one or two actions, note them on index cards and take them into the next iteration's planning game.
The format above worked well. It generated the following actions to carry forward:
- Strive for slices
- Ask for help and offer help to others
- Pair promiscuously
There was lots fun and smiling faces, it relaxed everyone and put them in a positive frame of mind, which helped the planning game (that follows our retrospective) go more smoothly.
Tags:
retrospective,
appreciative inquiry
Links to this post
Looping the loop
We entered the loop at speed.
We went up, over and down and came out the other side faster
and stronger for the shared experience.
All teams have blips. Gus and I had sensed growing frustration in our team over the last few iterations - sniping, bickering, moaning, negative comments. Morale was starting to be affected. We opted to hold off for a couple of iterations and tried to coax out the root causes indirectly through the retrospectives, hoping that the team would become more aware and take remedial action. In the end, when the team
norms were breaking down and a lack of respect started to emerge, we quickly decided to tackle the problem head-on. We canceled the next
retrospective and informed the team that instead we'd be holding
one-to-one sessions. (This upset the team further because they love their weekly retrospective but we held firm.)
The one-to-ones proved very effective and were just what the doctor ordered for the team members and for us. We realised that actually things weren't really as bad as they appeared. The general frustrations were around learning a new technology (
Grails), people perceiving others to be not as committed, people cutting corners and not being held accountable, ambiguous information sharing and story myopia leading to a lack of teamwork, especially around preventing
slop. Chatting about it all reminded people of their responsibilities to the team and helped people generate some great yet simple ideas for making things better and getting the team back of track.
The one-to-ones cleared the air and we've made some small changes that have completely transformed the team. The small changes so far include:
- A more conscious effort to vertically slice stories to create opportunities for collaboration with (and obtain feedback) from QA, the graphics designer and the Product Owner). The rule of thumb is at least one slice a day. People are taking a little time now to think how they will build the story out using slices before jumping in.
- In the daily stand-up when story owners talk about their card, they now mention their pairing partner and speak only in terms of the acceptance tests:
"So far x out of y acceptance tests have been satisfied. Yesterday, so and so and I completed acceptance tests a and b. Today, I will pair with someone to complete acceptance tests d, e and f"
- Again, in the daily stand-up story owners request any specific expertise they might require during the day and when they think they will need it. At the end of the stand-up when we form pairs, the team organizes itself so that the right skills can get to the coalface on each card.
- Pairing is more promiscuous. The Grails expertise and styling (CSS) expertise are now being transferred more effectively spreading the knowledge and building skills redundancy into the team.
These are simple changes we've made many times before with other teams. Sometimes blips happen because we take our eye off the team.
With respect and trust restored, the team norms have returned. There's a stronger sense of team. Everyone is asking for help and offering help. Collaboration has gone through the roof. The net results: The team is happy, healthy and
hustling, and the velocity has doubled.
Tags:
team,
daily stand-up,
retrospective,
one-to-one,
vertical slice,
pair-programming
Links to this post
At last an organisation willing to try
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:
"This is the first time I've visited a team where everyone clearly knows exactly what's going on in the project."
This is the first corporation where I've experienced a groundswell of vocal and active support for an agile approach to software product development at the very top of the organisation. It's down to the enthusiasm and drive of the department CTO and the Head of the Online Business Unit, some internal marketing, and our ability to make commitments and deliver predictably and reliably. Long may it continue, as this is just the beginning of this roller-coaster ride.
Links to this post
Become part of the status quo or leave?
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?
Tags:
kaizen
Links to this post
Who am I to question the value of low quality software to the customer?
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.
Tags:
quality
Links to this post
Standard work is only the best way so far
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.
Tags:
agile,
kaizen,
standard work
Links to this post
Knowing right from wrong
Guess what? There are right ways to be agile and there are wrong ways to be agile. Yup, I said the words "wrong" and "agile" in the same sentence. So shoot me.
Links to this post
Should you always do what the customer wants?
If the customer says he doesn't want "perfect code", he's happy to take low quality code as long it does what he wants it to do, what do you do? We're here to deliver what the customer wants, right. So, do you cut corners on quality? I wouldn't. I'd want to understand the customer's thinking and if it turns out that it's short-term thinking ("I want the cheapest solution so I don't care about quality"), or it's ignorance or plain old stupidity, I'd walk away. My conscience wouldn't permit me to compromise the quality of my work.
Tags:
quality
Links to this post
