XPDAY2006: Courage - How brave are you?
Courage - how brave are you? was a goldfish-bowl discussion facilitated by
Giovanni Asproni about
courage and it's opposite, fear. This was the final session I attended on the second day and I was pretty pooped. There was a reasonable turn-out but understandably it wasn't as energetic as the first
goldfish-bowl about simplicity. Nevertheless, it was an interesting discussion about a subject I feel strongly about.
Fear is endemic in the world of software development. People fear taking longer to do something than they estimated. People fear missing deadlines. People fear saying what they really think. There are too many fears in the industry.
Giovanni said
fear usually leads to inferior results and failure, which causes stress. And guess what that causes ... more fear! It's a vicious cycle.
I like to define
courage as your ability to take decisive action in the face of fear. Things get done when people demonstrate courage. Have the courage to show vulnerability. This will help build trust in the team. Have the courage to make small decisions and reverse them if they don't work out. Have the courage to fail fast and learn. Have the courage to make commitments and be held accountable for them. Have the courage to demand fun in work.
Feeling empowered in a trusting environment breeds
courage. Command-and-control creates a blame culture and breeds fear. Funny that! Who'd have thought? Things don't get done when people are afraid because, like a rabbit in the headlights of an oncoming vehicle, fear causes paralysis. Decisions don't get made, actions aren't taken, and opportunities aren't seized.
If you can find the
courage to be courageous you will find a new way of life. A weight will be lifted. So do yourself a favour and be courageous. Free yourself from your fears. Come on, seriously, ask yourself: In the grand scheme of things, what's the worse that could happen? As
Jonathan Clarke said:
I only regret the things I didn't do.
Tags:
xpday,
courage
Links to this post
XPDAY2006: Why is simple so difficult?
Why is simple so difficult? was a goldfish-bowl discussion facilitated by
Nat Pryce and
Jonathan Clarke. It was an energetic session with people pinging in and out of the bowl at a rate of knots. Here's some of the things that were said:
- Simplicity emerges. We should be saying - have the simplest thing, not do the simplest thing.
- Dan North said simplicity is clarity of intent. How clearly can I express intent? If redundant code supports clarity then I'm ok with that. I like 'clarity of intent' as a definition for simplicity.
- Steve Freeman said code is an aesthetic experience as well as a technical experience. If code isn't simple it'll suck the life out of you. As craftsmen there is a sense of pride we take in writing simple code.
- Someone asked - should we be talking about least complexity rather than simplicity?
- It isn't good to be fastidiously tidy. If the code is pristine you don't want to touch it for fear of breaking a work of art. A little mess is therefore a good thing.
- Accidental complexity is a natural by-product of developing software. We're very good at creating this tacitly.
Tags:
xpday,
simplicity
Links to this post
XPDAY2006: Love in the Age of Software
For the past two days I've been at
XP Day 2006. This morning I arrived at
Ironmongers Hall on autopilot and took a seat for the keynote speech, not yet fully awake. I was woken sharply by noise; a lot of it. The session,
Love in the Age of Software by
Robert Biddle and
James Noble had started.
It was a truly bizarre session in terms of its style. Lots of noise, music, presenters talking over one another, repeating what the other had said to simulate some kind of echo. I was confused at times and just couldn't figure out what was being said, but I eventually tuned in and was able to follow along. That said, credit goes to the presenters for doing something different. It played out as a tumultuous conversation between the two presenters, who dropped in and out of different characters. I thought getting us all to stand up and recite the
Agile Manifesto, like the Lord's Prayer, was worth a chuckle. As was the short dialogue about which is more macho, a
train wreck or a
death march.
I liked the direction they were taking when they declared their distaste for
wimpy agile:
- System metaphor: Most neglected practice - EXPUNGED.
- Onsite customer: Apparently impractical and unrealistic - EXCUSED.
- User stories: Promise to have conversations - AUTOMATED.
- Planning game: Embrace change .. but not for us - RESISTED.
Red bar,
green bar was a recurring theme as they explored the relationship between the customer and the developers, and how their perception of events and outcomes differ. For example, developers may see project results as
technical success while the customers see
business failure.
The essential message was this:
If the customer and the developers don't love one another then the agile magic cannot happen.
Tags:
xpday
Links to this post
Another heartbeat retrospective
The other day we tried a different format for our
heartbeat retrospective. The iteration was a tough one and I saw some old problems recurring. So I thought we'd try some root cause analysis to get past the symptoms to see if we could identify what was really causing the problems.
Here's the format:
1. Prime Directive: A team member read it aloud and then, in turn, I asked ask each person to say whether they could agree to it.
2. Good and Bad (5 min)This is a simplification on the brainstorming technique Mad, Sad and Glad.
The team split into small groups. Each group was asked to think back over the iteration and brainstorm the events that were either good or bad. Good events were written on green post-it notes and bad events on pink post-it notes. It helped the groups to categorise the related notes.
retrospective-goodandbad3
Originally uploaded by sjb140470.3. Patterns and Shifts (5 min)In this activity the groups looked for connections between the events to see if any patterns existed. Each group was asked to identify the most important pattern to analyse.
4. 5 Whys (30 min)The groups used the
5 Whys technique to reveal the root cause for their selected pattern or event. This generated some interesting discussion.
Each group presented the root cause they identified to the rest of the team.
5. What Can You Do About ItThe groups reconvened to discuss and agree on an action they could take into the next iteration to address the root cause they had identified. Ideally this was captured as a user story. The user stories were presented to the rest of the team to solicit a team-wide commitment to the actions.
Tags:
retrospective
Links to this post
Courage, dear boy!
Compromised agility is, more often than not, the result of a lack of courage to seek, and to persist until you achieve, necessary change.
Courage is an important value for me.
It is not the critic who counts, not the man who points out how the strong man stumbled, or where the doer of deeds could have done better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood, who strives valiantly, who errs and comes short again and again, who knows the great enthusiasms, the great devotions, and spends himself in a worthy cause, who at best knows achievement and who at the worst if he fails at least fails while daring greatly so that his place shall never be with those cold and timid souls who know neither victory nor defeat.
Theodore Roosevelt. From a speech given in Paris at the Sorbonne in 1910
Courage is going from failure to failure without losing enthusiasm.
Winston Churchill
Tags:
courage
Links to this post
Supporting change
Compromised agility or
agile mediocrity can be achieved in a command-and-control environment. Full-on agility can't. And so you miss out on all the benefits that come along with it: A whole new level of improved quality and increased productivity, creativity, accountability, leadership, energized work, motivated people and fun.
If you're an executive manager serious about being agile and you're in a command-and-control environment you should start changing things to achieve lasting success. Start with the culture and the organisation and then move onto the people.
Agility will not happen when
scientific management prevails. The values and principles are diametrically opposed. Disband the command-and-control institutions and get rid of the traditional management mindsets. You need to be
thinking of agile as a leadership mindset and an omnipresent culture that is built on trust, honesty and courage, and
- allows teams self-organise
- empowers people at the coal-face to make their own decisions
- facilitates collaboration, open communication and information sharing
- tolerates mistakes and encourages constant learning
- drives a continuous flow of business value to the customer
- energises people and creates a buzz
- seeks to eliminate waste and bureaucracy
Create a place where people want to work.
That said, agility will not happen without the right people. Given long enough, I'm convinced a command-and-control will create
theory-X people. You want
theory-Y people who have the right mix of talent and integrity to get things done. Don't have people tell other people what to do. Ask people to make commitments to one another about their work and what they will deliver. And ask them to hold one another accountable to those commitments because delivering against commitments builds trust.
Dissolve groups of people who are siloed according to their roles, e.g. QA, Architecture, Project Management, etc, and instead build cross-functional teams organised around single and coherent products or services. These teams should include all the necessary skills - programmers, testers, sysadmins, DBAs, etc - to make decisions, take immediate action and get things done. People in a team work together so colocate them. Give teams the space to succeed and trust them to get things done.
Don't use managers. Find leaders who will facilitate teams, maintain focus on the big picture and common goals, and preserve the new culture.
Without the vocal support and encouragement of executive management coupled with visible demonstration of adherence to common values and principles, an organisation will not commit to change.
Tags:
agile,
change
Links to this post
Making room for a big visible screen
We continue to make our
bullpen a more
informative workspace. Today we relocated our
planning boards to make room for our new 32" screen. This replacing our 18" monitor showing the
cruisecontrol dashboard and
selenium test runs. I want to get picture-in-picture working so that we can radiate other information at the same time.
Informative Workspace
Originally uploaded by sjb140470.Tags:
informative workspace,
information radiator,
planning board
Links to this post
Our bullpen has its own race track
More fun and silliness in work. Today I bought
Granny Racers from
Maplin Electronics and installed it in our
bullpen. Qualifying heats start tomorrow. Who'd have thought a granny in a wheelchair was inherently unstable at speed; must be the high centre of gravity and high profile. The wind factor when taking bends at speed makes them prone to flying off the track. They're also liable to get a wheel stuck at the chicane.
Granny Racers
Originally uploaded by sjb140470.
Links to this post
What's keeping me up
In the think-tank at the
APLN Leadership Summit we were asked, as agile practitioners what's keeping us up at night? I'll let these people answer for me:
Tom DeMarco:
The mainstreaming of agile methods is more apparent than real. What's definitely a trend is that companies are beginning to claim affiliation with agile approaches. This is a necessary step on the way to actually changing, but it doesn't imply that any real change of method has yet happened. I see a willingness to pay lip service to much of what the agile movement stands for, to endorse it as reasonable and practical, but no great willingness to adopt it.
Christine Davis:
The agile paradigm may philosophically conflict with some of the most valued strategies and processes being embraced by management. There is little management experience at the higher levels with using agile on large programs or projects, and no experience with corporate-wide adoption of agile processes. How do we reshape and reinvent to be fully agile and not simply dress up the things that we are currently doing so that they merely appear to be agile?
Lynne Ellyn:
Looking at enthusiastic adoption of agile by software developers, we see a mix of motives. Many are earnestly motivated to produce high-quality code in a quick and efficient manner, while having fun doing so. Other practitioners are motivated by a desire to do only the fun and creative side of software development and are looking for an excuse to abandon all forms of discipline.
Agile methods will likely fall into disfavour if corporate experiences with the agile approach are the preview of development teams motivated by adolescent fantasies of freedom from appropriate discipline.
Joshua Kerievsky:
I worry that the industry's misinterpretation of Beck's words is leading many on a path to agile mediocrity. So many teams I visit or hear about these days are saying they are "doing XP" when they are only practicing a miniscule percentage of XP. Mediocre agile efforts aren't going to cut it on the world stage. To thrive in today's world, organisations must harness the full force of agile methods.
References:
1. Agile: From Rogue Teams to Enterprise Acceptance, Business Technology Trends and Impacts Vol. 7, No. 9, Cutter Consortium
2. The Expert's Guide to Agile: Beyond the Basics, Agile Resources, Agile Project Management, Cutter Consortium
Tags:
agile
Links to this post
She's a beaut!
My new
MacPro is a real beauty.
My new MacPro
Originally uploaded by sjb140470.
Links to this post
Constructive disruption and compromised agility
UPDATE: A
new version of the Agile Zealot's Handbook is now available.
On Wednesday night I was the guest speaker at the inaugural Agile Practitioners Forum, organised by Les Oliver and
Simon Voice and sponsored by
Radtac and
Connections Recruitment. The venue was the Gun Room aboard the
HMS Belfast, which is moored on the Thames river. The session was called
Simon Baker's Soapbox. It was a 15-minute discourse that I delivered with
Mauro Talevi and
Gus Power.
The audience included many experienced agile practitioners and coaches so I wanted to do something a little different. I wanted to be provocative, in a nice way of course, to stimulate a discussion about something that I, and
Gus and
Mauro, feel quite strongly about. I worry that the values of courage, respect, simplicity, communication and feedback and the
principles of the Agile Manifesto are paid lip service by many companies adopting agile methods. I wanted to hear what others thought about this and whether we could do more to help companies understand the part values and principles play in making agility work.
Below is a transcript of our 15-minute patter:
"Anyone who knows me knows that I have a tendency to speak my mind and that I'm not always politically correct. I also have an anti-establishment streak. If I'm the bad cop today, then Gus is worse cop. We've both been engaged as coaches by companies with institutional command and control structures. And we've had lots of fun. I call it constructive disruption. Mauro, however, is a more balanced kinda guy. At least until he's had a few glasses of wine and gets the urge to dance.
More companies are trying to achieve agility. And more companies are failing to achieve agility. More and more I'm hearing "Oh we tried Agile but it didn't work for us". I'm not surprised. I see companies focus entirely on practices or adapt things before they've even tried them.
Why are companies focusing entirely on practices? Poor education? Maybe and it's unforgivable! Conscious ignorance? That's being stupid! And it gets worse when they cherry-pick. As for gradual adoption of practices: It's glacially slow. The benefits are slow to emerge and it's difficult to see how the practices all interconnect.
Why are companies adapting things before they've even tried them? How many times have you heard: "Oh that wouldn't work here"? How can you know until you've tried it? I thought adaptation was supposed to be based on empirical feedback? Try something, inspect the result and then adapt.
As agile becomes more commonplace, more people are saying agility is all about adaptation, we take a different view. While adapting is a key part of our agility we still think it's about the values and principles. The values and principles help us create the mental environment that helps us achieve agility. Without them we are not set-up for success. We think we should be getting more precious about them. More vocal about them. More protective. And less tolerant of companies that ignore them.
Companies are ignoring the values and principles. They don't understand their importance. And they're not prepared to change the organisation and culture to incorporate them. But it doesn't really help when some of the principles of the Agile Manifesto are ambiguous. However, like the HSBC adverts on TV, the principles can be interpreted differently in different cultures. Different organisations see something as adaptation while others might see it as compromise.
So we rewrote the principles of the Agile Manifesto to be less ambiguous and called it the Agile Zealot's Handbook:
VALUE
IF you don't repeatedly release software
into a production environment
at least once every month
that realises business value
for a real customer...
TECH
IF you're not paying constant attention to technical excellence
with simple, effective, incremental design
driven by continuous, repeatable automated testing
with at least 95% coverage...
LEARN
IF you're not learning
through inspection of every iteration
and adapting and improving
all of the time...
TEAM
IF your team is not empowered to self-organise,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...
THEN YOU HAVE COMPROMISED YOUR AGILITY
Ok. So perhaps we're being deliberately provocative here. But we're trying to make an important point. Too many companies are using the term 'adaptation' to get out of incorporating the values and principles. I call this compromised agility.
Ultimately I see no winners here. These companies don't win because their projects still fail or they don't get to experience the results and fun agility can generate. And we don't win because I believe agility is devalued by what these companies are doing."
The DiscussionThe discussion that followed lasted for 90 minutes. It touched on many aspects, we heard many opinions and it included agreement and disagreement. Some people thought agile methods are too dogmatic. Others thought they're at their best when they're dogmatic. Some said adoption of agile methods needs to be gradual because people can only assimilate change in small steps. Others said adoption should be all at once so that people experience how all the practices work together and realise benefits more quickly.
Someone asked "does it matter if your agility is compromised?" If you're delivering business value perhaps it doesn't matter. But are the people motivated, creative and having fun? At the
Agile Business Conference, Kent Beck asked rhetorically: "How would you develop if it was your money?" If it was my money I'd spend it on a team that doesn't compromise on its agility because I believe they'll produce more business value at lower cost, repeatably.
I was pleased when someone said that "often our values are in conflict with those of management". I believe the values of courage, respect, simplicity, communication and feedback and the
principles of the Agile Manifesto are most at home in a trusting environment where people are empowered and organise themselves to get things done. I don't think you can create this environment within a command and control management structure. I think companies pay lip service to the values and principles because they're unwilling to undergo organisational and cultural change.
I'll leave you with this:
Care more than others think is wise; risk more than others think is safe; dream more than others think is practical; expect more than others think is possible.Pictures from the evening:
Addendum:Here are the points noted during the discussion:
- You don't need to be dogmatic to be agile.
- And you can't be dogmatic in every domain, e.g. you can't release regularly in a highly regulated industry like pharmaceuticals...
- But it's better when you are dogmatic.
- Sometimes you have to pick and choose because some organisations won't permit, say pair-programming...
- Yes, and it's this attitude that compromises your ability to be agile.
- Agile values and principles are often in conflict with those of management.
- You have to introduce change gradually otherwise people will resist...
- But it then takes so long to become agile that teams don't see how it all works together. Introducing it all at once helps people experience 'the whole' and see how its greater than the sum of its parts.
- What is technical excellence?
- As an agile team a lack of courage can compromise your agility.
- Being agile doesn't guarantee success.
- This is all nice in theory but in reality it can't work. Agility has to be more about adaptability.
- Does it really matter if you compromise your agility?
Tags:
agile values,
agile principles,
compromised agility
Links to this post
Drawing burn-up charts on overlays
We now have 3 teams working on 3
product backlogs (all in the same
bullpen). And we've run out space. We don't have room for 2 additional whiteboards on which to draw their
burn-up charts. So we improvised.
We now draw each teams
burn-up chart on a transparent overlay which is clipped to the whiteboard at the top. The axes are drawn on the whiteboard underneath, and everything pertaining to a project's iteration burn rate (tracked and target ideal pair days plus tracked and target number of running tested stories) is drawn onto the corresponding overlay.
Iteration burnups on overlays
Originally uploaded by sjb140470.This mechanism allows us to view each team's progress next to one another and obtain an holistic view of how we're doing. It works really well because when we're updating one we don't accidentally erase or smudge another.
Tags:
burnup chart,
big visible chart
Links to this post
ABC2006: Diana Larsen's Retrospectives for Change
It was good to finally meet
Diana Larsen at her Retrospectives for Change workshop. Retrospectives help to build trust and morale in the team while improving productivity and capability and increasing quality.
Diana's session reminded me to do the following:
- Post an archive of the last few retrospective outcomes on a publicly visible wall.
- Take shared responsibility for the outcome.
- Reinforce change by reminding people of the noted action/s from the retrospective (we try to capture these as user stories).
Tags:
retrospective
Links to this post
ABC2006: Kent Beck - Agility is not enough
The weasel is agile and fast. But
Kent asks "would you trust one? Other than agility what else do individuals, teams and organisations need?"
He identified the following:
Trustworthiness: People are trustworthy when they do what they say they'll do, promise no more than they can deliver and maintain good intent.
Responsibility: "How would you develop if it was your money? Would you spend it on a PRD?" You want low cost and high value delivery. Be aligned with the vision because "it's easier to choose features when you know why you're doing it." And "software is a long game so a sustainable pace if essential."
Accountability: "Being accountable is a step towards being considered trustworthy." Be honest. Have nothing to hide. Work in steps of real functionality. And ship early and ship often.
Awareness: Reflect on your work, your choices and their implications. Be aware of others. Respect them and their needs and the feedback they offer. Learn to read emotions in faces, tone of voice, and body language.
Kent says "it boils down to learning, which involves practices, technology and people skills. Successful businesses need trustworthy accountable behaviour from individuals and organisations."
Listen to what
Kent is
thinking.
Tags:
agile business conference,
agile
Links to this post
ABC2006: Snippets of wisdom
Here are some of the smaller snippets of wisdom I took from the
Agile Business Conference:
- If a man is hungry, you can give him a fish. Better still, you can teach him to fish. Better still, you can teach him to invent a way to fish - Sean Hanly.
- Extreme Programming forces the business to come down to the developers' level. Scrum forces the developers to come up to the business level.
- Focus your customer on results not methods.
- You want repeatable results not repeatable process - Sean Hanly.
- If it was your money would you spend it on writing a PRD? If it was my money I'd want to see working software - Kent Beck.
- Self-organisation pushes decisions down and out.
- Have the customer define the budget. And let the team own it.
- Sean Hanly talked about Shu Ha Ri as the phases of learning reflected in the adoption of agile methods.
- Shu: Dogmatically follow the techniques to learn their intricacies and understand how and why they work.
- Ha: Break away, using your expertise in the techniques to adapt them and learn their limits in different situations.
- Ri: Achieve fluency with adapted techniques.
- I liked Todd Little's analogy for planning with uncertainty using Hurricane Rita's projected path. You couldn't predict where Hurricane Rita would eventually hit the south coast of the US but you could manage for the uncertainty.
Tags:
agile business conference
Links to this post
Celebrate every success
In work I sit next to
Jeff of
Coedit. Jeff and his programming partner were working on a story card when Jeff suddenly said "Damn! There's a whole lot of success happening here."
First I laughed. And then I turned and said to Jeff "what a great thing to say". And it is.
Jeff was clearly buzzed by the progress they were making. And as a coach that kind of enthusiasm in people drives me. Anyway, I digress. My point is this: It's important to celebrate your small successes aswell as your big successes. Any size success is still success.
Party on
Jeff!
Links to this post
If you would like help finding people who have experienced agility, I recommend you speak with Simon Voice at
Connections Recruitment.
I'm often asked by clients to set-up teams for agility and this often requires recruitment effort. I've worked with Simon on a number of engagements and it's always a pleasure. Simon and his team work proactively and enthusiastically to understand what I'm looking for. They tune into your thinking. They don't farm CVs. They understand that agility is about people and they take the time to get beyond the technical experience to look at what I call the soft skills before they put forward any candidate.
Simon won't hassle you or saturate you with inappropriate CVs. He'll just get done what you ask of him. It's both enjoyable and productive when you can work with a recruitment agency who fundamentally understands agility and what makes it work. How many agencies can you say that about? Not many.
Tags:
agile business conference
Links to this post
Gus Talks on Retrospectives: Attack of the oversized story cards
I'd like to introduce you to
Gus Power. I've been working with Gus since June and I'm always ready to learn from him. He's one of the few coaches in the UK with lean manufacturing experience having worked at Dell while they engaged consultants from Toyota. Gus is full of ideas and insights and I'm pleased he's decided to blog about a recent
heartbeat retrospective he facilitated with our team. So, without further ado I pass you over to Gus:
For this weeks' iteration retrospective we tried a homegrown variation on the usual heartbeat format. The idea was to condense the brainstorming and dumb mapping exercises into one activity, using the familiar representation of business value - the
story card - as a guide.
We drew up some big story cards on flip-chart paper and labeled them. In this instance we used the categories:
- Slicing and Progress
- Story detail
- Ownership
- Tracking
- Estimation
- Pairing
- Acceptance testing
The cards were stuck on the wall and the team was divided into small groups of 3-4 people. The team members brainstormed aspects of the past iteration using post-it notes - blue for good and pink for bad. These were stuck on the relevant area of the story card. It's useful to have the iterations' story cards available for reference.
Written by:
Gus PowerTags:
retrospective
Links to this post
If you get the opportunity to hear
David Taylor speak I recommend you take it. His style is energetic, enthralling and uproarious. His message is simply this:
Be successful, by being yourself.
Here are some of the memorable things David said on the day:
What would've happened if an IT Director was in charge of the Titanic?
Well, he would've missed it ...
By 2 years!
Don't have a Plan B because you'll always achieve it.
If you do what you've always done, you'll get what you've always got!
Here's a
taster of David (bear with the singing at the start ;).
Tags:
leadership,
agile business conference
Links to this post
ABC2006: Exploring Agile Factors
At the
Agile Business Conference I went to the
Exploring Agile Factors session hosted by
Rachel Davies and
Steve Freeman.
I'm a big fan of
chartering because it helps a team to identify the project vision and its community, the project success criteria, its constraints and assumptions, and it also helps a team to establish working agreements regarding how they will apply agile methods. I came away from this session with lots of new ideas and questions to use in my next chartering workshop.
Tags:
chartering,
agile business conference
Links to this post
Last week I spent a day at the
APLN Leadership Summit and 2 days at the
Agile Business Conference. It was the first time I've been to the conference and, on the whole, I'd have to say that I was disappointed. However, conferences always have some gold nuggets, and this one was no different. I'll talk about these in the coming posts.
APLN Leadership SummitI had high expectations for the
APLN Leadership Summit. The word 'Summit' in the title led me to believe the day would be a meeting of leading thinkers and practitioners from the Agile community, but there were only a few present, probably less than 10.
Now my agility depends on an open and trusting environment with empowerment, self-organisation and leadership, and I wanted to hear and talk more about these. The presentation, tutorial and think-tank topics tried to achieve this but the sessions were often hijacked because the majority in the audience were fixated on
scientific management and contractual obligations rather than on leadership and collaboration. This, in my opinion, devalued most of the sessions.
I think it was a mistake of the
APLN to partner with the Agile Business Conference (operated by the
DSDM Consortium) to host their first UK Summit. Perhaps if they'd have done it independently it would have attracted a broader cross-section of people from the Agile community. I believe the
APLN is still trying to find it's place in the Agile community but I do think it's focus is an important one. Maybe I should attend the US Summit next year?
Agile Business ConferenceI thought the
Agile Business Conference delivered a confusing message about agility. And those people that I spoke to who came to the conference to find out how they could achieve agility felt the same way too. There was too much focus on tactics and practices. And these can vary significantly across the various styles of agile methods. But I can't help wonder if this comes from the bias towards DSDM, which still strikes me as process-oriented and not people and purpose-oriented. With the exception of
Sean Hanly's and
Kent Beck's keynote speeches, there wasn't enough focus on common underlying values and guiding principles for my liking. This is where my coaching focuses. The word 'agile' is being used to mean so many different things that it is becoming meaningless.
One benefit of the conference was the productive networking, although I think the credit really needs to go to the
Moo cards. These proved to be a big hit with people, with recipients showing them to other people who would then come and ask for one.
A view from the
Queen Elizabeth II Conference Centre:
View from Queen Elizabeth II Conference Centre
Originally uploaded by sjb140470.Tags:
agile business conference
Links to this post
Settling into a new bullpen
A few weeks back we moved offices. We had to endure 2 weeks back in a pod arrangement but now we've got our new bullpen organised.
Tags:
bullpen
Links to this post
Team on the planning board
We use magnetic
planning boards. When a pair starts work on a story card they take the card away to their workstation, but when they return the card to the
planning board they often forget where it was located. The coloured dot on the card indicates which column it was in (Not Started, In Development, UI Review, QA Test Review, Customer Preview, Done), but they don't remember the vertical position. This is a problem because the story cards are arranged vertically in business value order, with the highest business value card at the top of the board.
To overcome this we used personalised magnetic placeholders to occupy the space left by the story card. The magnets were in the shape of a running man (of sorts) logo and we glued team members faces to these. However, due to a global rebranding exercise, we couldn't get hold of enough of these magnets for the entire team.
In his blog post about
build-o-matic and the visibility of the build results,
Ivan Moore recalled using
South Park Studio to create pictures of everyone on the team for use on the
planning board. Great idea! I remember seeing links to
South Park Studio circulating some months back. So I had each team member create a character of someone else on the team. This was lots of fun. I followed Ivan's description and printed the pictures out in colour, laminated them but I stuck magnetic squares to the backs instead. You've seen the
team on the wall. Now meet the team on the planning board.
Tags:
agile,
planning board
Links to this post
You're in my way
In the
daily stand-up, team members state any obstacles that are stopping them getting things
done. Obstacles either exist or they don't. They are either blocking or they've been removed. Of course, it's good to know that someone is working to get an obstacle removed but while that work is ongoing the obstacle is still blocking something getting
done. So don't let obstacles hang around. Make them publicly visible as soon as you become aware of them and go to work immediately to get them removed. If an obstacle can only be removed by someone else, solicit that person's help straight away and then do everything in your power to ensure that person removes the obstacle as soon as possible.
Tags:
scrum
Links to this post
Scrum talk at Google
Ken Schwaber talks about
Scrum at Google.
Tags:
scrum
Links to this post
