Bit by bit or all at once?
In his book
The Fifth Discipline, Peter Senge says:
From a very early age, we are taught to break apart problems. This apparently makes complexity more manageable, but we pay a hidden price. We can no longer see the consequences of our actions; we lose our intrinsic sense of connection to a larger whole. When we try to 'see the big picture', we try to reassemble the fragments in our minds, to organise all the pieces. But, as physicist David Bohm says, the task is futile - similar to trying to reassemble the fragments of a broken mirror to see a true reflection. Thus, after a while we give up trying to see the whole altogether.
I think this difficulty emerges when a team tries to adopt only a few
Extreme Programming practices at a time. It's understandable why this approach is taken. Most people assimilate new things when they're introduced gradually. Too much, all at once, and people can feel overwhelmed. In my experience, however, when you take this approach teams struggle to pull it all together. They compartmentalise the practices and do not realise the whole that is
Extreme Programming. So, if I have a choice, I will always introduce everything in one go and then help people to bring it all together, everyday in all that they do. Certainly it's a challenge for people to learn this way but it's definitely not impossible. And when they succeed it's a measure of their abilities.
Tags:
agile
Links to this post
Peacocks and penguins
Over Christmas I read
A Peacock in the Land of Penguins, which tells the story of Perry the Peacock hired into an organisation staffed mostly by penguins. Essentially, it's a corporate fable about creating a culture of creativity and courage inside an institutionalised organisation.
Perry grew up in the Land of Learning where you first imagine something, then you try it, you prove it, and finally you actually do it. With the buzz of competition and
hustle you have to
work hard, learn fast, and live by your wits and creativity to achieve success. Constructive disagreement is valued because everyone believes that's how new ideas get tested, change is introduced and progress made.Perry was lured away by the penguins to the Land of the Penguins. But it became increasingly evident that he didn't fit in. He saw
bureaucracy everywhere. Penguins were organised by hierarchy and teams were divided by roles and responsibilities. Everyone was expected to work within the standard process. Despite being hired for his unique talent and flair, Perry was constantly under pressure to act and dress like a penguin. He resisted,
firm in his conviction that he should be valued for his results. Rather than conform and let the culture change him, Perry tried to change the culture, but
all his strategies met with resistance and red tape. All his ideas were dismissed and his efforts came to nothing. Whenever he asked "Why?", he got the standard response "That's they way we've always done things around here".
He learned through painful experience that the culture was deeply entrenched.Perry knew
there must be at least one land in the vast Sea of Organisations where he could be a peacock and be valued for his uniqueness. And so he left for the Land of Opportunity where individuality was welcomed and nurtured, knowledge was shared, and everyone had confidence in their leaders because they had risen to their positions through talent, skill, and ability. Here, everyone recognised the importance of acceptance and trust because they
make it possible for each bird to sing its own song, confident that even those who sing with a different voice will hear it. Perry came to realise that
the Land of Opportunity is more than a place - it's a state of mind.
Tags:
organisation,
culture
Links to this post
For the last 8 weeks one of our teams has been developing an experimental application called
badjit. And we've now put the first incremental release to production. The concept is simple -
badjit is a
social network that connects people via their shared passions. Visit
badjit now and have your say. Say what you really think and explore what other people love and hate. Obviously, after only 8 weeks the functionality is basic but we've got a
product backlog full of goodies coming in the New Year.
The project was the brainchild of one of our
product owners. An objective of the project was to demonstrate that an idea could be taken from conception to production in a few weeks and without a requirements specification by using a co-located
product owner and
agile team.
Tags:
incremental release
Links to this post
'What's the difference?!'It seems that there's a lot of confusion about these terms of late.
Values. These are the ideals that a group of people embrace. They can be positive or negative - e.g. empowerment or control. These values are implicit in the personality or culture of a company. Values are often emotive - they represent driving forces behind people.
Principles. Although the word stems from the Latin for leader or emperor, in this context we're talking about it as a general law or essence - e.g. principles of modern physics
Practices. The easiest one to grasp - a set of repeatable actions you perform. Practice the flute. Practice loyalty. Practice developing software by driving with tests. OK, that one's easy.
So how do these terms tie together? A practice works in a given context due to an underlying principle or principles. For example, the practice of employing small easy-to-adjust tooling machinery in place of one large cumbersome automated device is more productive for a manufacturing line with varying output requirements. The underlying principle is basically to 'smooth the value stream' - reducing bottlenecks to enable flow. Continuous integration is a software development practice that is backed by the same principle. For an individual to adopt a practice they must see that the practice works in the field and understand the principle(s) behind it.
How are values related? Practices produce effects that support one or more values.If a development organisation values the ability to meet their customers needs (rather than make the customer fit their needs as so often happens), then a practice such as TDD will support that value as it keeps the cost of change low over time (the principles, to name but a few: once and once only, simplest thing that works). This is where Agile/XP teams often run into difficulty with organisational structure - many of the practices support values that are not necessarily consistent with those of the organisation (empowerment being a key example). Worse still, a company may have no common values (perhaps due to a lack of common vision or leadership) or different elements of a company may hold conflicting values.
Tags:
agile values,
agile principles
Links to this post
Agile finances?
I'm currently interested in getting financial skills into agile teams because I think better value for money can be achieved if the team has these skills and is made responsible for its own budget. I'm also keen to see an iterative approach to contractual payments, investments and budgeting. Rather than spending 300K in 1 large purchase, why not break it out into 10 30K purchases, paid on the delivery of concrete results, which may vary depending on empirical feedback? Without empirical evidence at the start, it's worth fixing the cost of the initial purchase.
To get some background, I'm looking into techniques for measuring the resultant value of delivered software, the cost of delivered software and the return on investment. I'm currently reading
Software By Numbers
with interest. At the
Agile Business Conference I attended Tamara Sulaiman's session on
Agile EVM. Tamara said EVM doesn't measure business value, it manages progress against a plan in terms of technical performance, cost and scheduling. She also said
Agile EVM works best with estimation units of relative magnitude, like
story points, rather than time-based units.
I need to read more and better understand the theories, but I'm going to try applying
Agile EVM to a release on my current project. I'd like to see what numbers come out and what they're actually telling me. I'm also going to try some of the stuff in
Software By Numbers.
Tags:
agile evm
Links to this post
ABC2006: Scaling agile
Colin Bird said when you scale it's even more important to understand the
principles (of the
Agile Manifesto). Damn right! So often they're compromised and you end up with something that just isn't that agile anymore. The practices also need to be consistent across the organisation.
Here's what I took from the session:
- Start off with a beach-head team to build a head of steam. Create a cross-functional team from early evangelists and opinion leaders. Keep the team together long enough to succeed. Start small and make the team progressively larger over time, until it eventually becomes too big. Then split out people to seed new teams.
- Create enough cause for people in different teams to talk to one another. If you cannot avoid distributed teams, maximise communication with instant messengers and VOIP solutions; use an integrated development environment with a common continuous integration environment; cycle people through all teams.
- Avoid communities of common disciplines, e.g. DBAs or architects.
- Stagger daily stand-ups so that people from other teams can attend.
- Synchronise iterations to allow joint planning and delivery.
More reading on
Colin Bird's blog:
-
Scaling agile - part 1-
Scaling agile - part 2Tags:
scaling agile
Links to this post
XPDAY2006: Joshua Kerievsky's keynote speech
Joshua Kerievsky of Industrial Logic gave the first keynote speech at XPDay. He talked about selling agile methods. Here's what I took from the session:
- When you sell something people will resist by voicing their objections. Most people interpret the objections as rejections and then become defensive. An objection is not a rejection. More often than not, the objections are founded on a lack of understanding. So inform them. Give them better information on which to make their decision.
- Most people try to sell something by selling its benefits. Instead, sell something by selling the risks of not doing it.
- When a team uses agile methods successfully, the surrounding organisation may begin to attack them (I've seen this happen so many times). Joshua described these people as organisational antibodies. The best thing to do is to start selling agile methods to the organisational antibodies as early as possible to lay a path for future agile projects and communities.
Tags: xpday
Links to this post
On average
Here's the content of a presentation I recently put together based on some averages derived from how we've been working.
Our Team:
Our teams are small, which enables us to adapt and respond quickly to change. We are co-located with our product owners. We are empowered to self-organise. Our teams include all the necessary skills to make our own decisions and take immediate action. We work in an environment where everything is visible, with information posted publicly on walls. We keep things simple and our process generates repeatable results.
Every project:Every project starts with a
chartering workshop that brings all stakeholders together. Among other things, we create a shared vision for the project, a goal road-map and the criteria for success.
Every 2 weeks:
Every 2 weeks we sit down with the stakeholders and plan, at a high-level, the next 4-weeks of work in the
product backlog.
Every week:
Every week we deliver a product increment that realises business value for our product owners and can be deployed to production. We deliver on time and on budget because we fix time and fix budget. Our product owner varies scope, if necessary. At the start of every week we plan in detail the highest business value work that we can complete within the next week. At the end of every week we learn by inspecting how we worked during the last week and we adapt to achieve improvement.Every day:Every day we concentrate on building product, not mock-ups. We
hustle because we care as much about the product as the
product owner. We hold a
stand-up to synchronize the day's activities. We make commitments to one another about what we'll complete that day and we hold one another accountable to those commitments. Every day we record
running tested features because it's the best measure of progress. It focuses everyone's attention, provokes more meaningful feedback, and we learn more about what we're building. We also re-estimate the work remaining to deliver our commitments for the week. We track these metrics on a publicly visible
burn-up chart. Everyone always knows where we're at with respect to our goals.
Every 32 minutes:
Every 32 minutes testers in the team collaborate with the developers. The latest software is deployed to our dedicated QA environment and exploratory testing is performed as the software evolves.
Every 20 minutes:Every 20 minutes we collaborate with the
product owner. Rather than having all business input up-front followed by a black hole until the final release, our
product owners are continuously involved, consulted and challenged. This is a different kind of product management. It's active product ownership that directly steers the development effort.Working together we make lots of small decisions to keep moving forward. We can make these quickly. And we can reverse them quickly. If one doesn't work we can go back and change it. We try different things, fail fast and learn, and we get things done. If we need to make bigger decisions, we make them at the latest responsible moment when more information is available.
Every 8 minutes:
Every 8 minutes we integrate changes with the entire code base and execute 1400 automated unit tests and 340 automated acceptance tests. Effectively, this provides continuous regression testing. The number of automated tests grow as new functionality is added because we employ
test-driven development. On average, we have less than 5 defects a week per product.
Every minute:
Every minute we pay constant attention to technical excellence with simple, effective, incremental design driven by continuous, repeatable automated testing. By programming in pairs, we perform continuous code reviews to bake quality in. We don't inspect for it afterwards. And we never compromise on quality.
Push to go live:
When we go live we click a button on the
cruisecontrol boxes. Our automated build runs, executes all the tests and then automatically deploys the applications to the production environments. Automated tests are then executed against the production boxes to ensure the deployment is successful. Manual intervention is not required.
By the end of the day
, developers and testers will have collaborated 16 times to perform exploratory testing, they'll have collaborated with the product owner 24 times, and completed 60 integrations, running 20,400 automated acceptance tests and 84,000 automated unit tests. Our test coverage is 88%.
Tags: extreme programming, scrum
Links to this post
I'm using lean thinking and lean concepts more these days when talking with managers and executives. And it's proving to be more effective than talking about agile this and that. Based on my own experiences and recent conversations with
Gus Power and
Steve Freeman, lean concepts are definitely under-utilised in software development, even if you're using the common agile techniques.
It's great working with Gus because, having come from Dell, he has extensive practical knowledge and experience about lean, so I'm learning all the time. At
XPDay, I went to
Pascal van Cauwenberghe's session,
The Toyota Way of Managing, to get a refresher. Here's a combination of the hand-out information and the notes I made:
PhilosophyEveryone and everything works towards a common strategic vision. Is every person adding value? If not, they're waste. Every person decides their own fate. Every person should accept responsibility for their conduct. And every person should continuously improve their skills to keep adding value.
Process- The right process will produce the right results.
- Create a continuous flow of work that delivers features to the market regularly. Release working software to production at least once a month.
- Establish a pull system where each step passes its result to the next step as fast as the next step can accept and process it. This helps to avoid overproduction and waste. Use index cards (kanban) to facilitate pull. For example, the product owner pulls features from the team a release at a time, while the team pulls user stories from the product owner. Pascal said that every 55 seconds a Toyota rolls off the production line because every 55 seconds a Toyota is sold.
- Eliminate waste (muda).
- Minimise inventory and work in process because it's waste. Keep a little stock and restock frequently. Inventory is features that aren't released yet, so release often. Work in weekly iterations to build up a release and then release every month.
- Be responsive to customer demands rather than schedules. Listen to user feedback after every release and let the product owner adapt the product backlog and steer development in response.
- Level out the load (heijunka), avoid overburdening people (muri) and avoid uneveness (mura) to prevent breaking flow by repeated stopping and starting. Toyota finalises its production schedule one day before the run begins. Everyone should work together at a sustainable pace to maintain flow. Each person should use energized work to maintain a balance between work and play and stay healthy and productive.
- Create a culture of stopping to fix problems and slowing down to get the quality right the first time. Every person is equally responsible for quality. If you notice a problem you have the responsibility to stop the production line. Don't continue to produce bad products. Use intelligent tools that automatically detect problems, stop themselves (jidoka) and alert people. Use cruisecontrol (or something similar) to perform continuous integration, with an extreme feedback device that lets people know when there's a problem with the build. If the build breaks, someone must take ownership and fix it immediately. No-one else can check code in until the build is restored.
- Repeatable techniques help achieve predictability and form the basis for pull and flow. They also give people time to focus on improving how they work. This leads to empowerment. Every person is responsible for improving how they work individually and collectively, every day.
- Capture accumulated learning about how you work. Use Shu-Ha-Ri as a way of thinking about how you learn a technique.
- Keep everything visible and understandable. Use simple visual indicators (andon) to help people understand what's going on, and to support pull and flow. Use information radiators such as physical planning boards, index cards and big visible charts, and keep them visible at all times by locating them in public areas.
- Use only reliable, well-tested technology that supports people rather than replaces them. But also encourage people to try-out new technologies that might improve how they're able to work together to achieve flow. Toyota says a machine is in its worst state when it arrives new in the factory. Over time they make it more reliable. Just like a new team.
People and Partners- Add value to the organisation by developing your people and partners.
- Grow leaders (sensei) from within who thoroughly understand the work, live the philosophy and teach it to others. At Toyota, a leader is always teaching two other people to succeed them. Apparently Toyota has expanded faster than its ability to grow new leaders.
- Develop exceptional people who live the philosophy. Provide them with continuous on-the-job training. Create and then empower self-organising, cross-functional teams. Work towards shared goals and continually reinforce the culture and philosophy.
- Respect your partners and suppliers. Show that you value them by challenging and helping them to improve. To maintain flow, Toyota's partners are required to perform at the same rates as Toyota.
Problem-solving and Organizational Learning- If you want to know what's really happening, go to the source and see it for yourself (genchi genbutsu). Only then can you really understand the situation and add value.
- Consider many options. Make decisions by consensus and then take action immediately. Ensure everyone who might be affected is involved (nemawashi - gently dig around the roots of a plant, in order to transplant it carefully). A decision reached by consensus is binding because it embodies an idea that's shared and supported by each team member.
- It's never good enough! Be a learning organisation through reflection (hansei) and continuous improvement (kaizen). Hold a retrospective at the end of every iteration to reflect, learn, adapt and then improve.
Apparently, it takes Toyota 5 to 10 years to get a new factory up-to-speed in the Toyota Way. Changing to a culture like Toyota's is not quick and it's not easy, but the rewards are worth the investment.
Tags:
xpday,
lean
Links to this post
Collaborative Workspaces: Keeping the Furniture Police at Bay facilitated by
Rachel Davies and
Mike Hill explored the constituent elements of effective and ineffective
informative workspaces and how they affect collaboration.
In the workshop we split into teams and were handed a brief that described an imaginary project for which were we to design workspaces. The first workspaces we built were from hell. The best hellish workspace had the developers (in the same team) physically separated by cubicles.
xpday6-collaborativeworkspaces10
Originally uploaded by sjb140470.QA was in the basement, under the table.
xpday6-collaborativeworkspaces11
Originally uploaded by sjb140470.While the business analysts were in the same city, they were actually located in a different office, over on the window sill.
xpday6-collaborativeworkspaces12
Originally uploaded by sjb140470.And the
product owner was in a completely different country, out of sight, on the mantelpiece.
xpday6-collaborativeworkspaces8
Originally uploaded by sjb140470. Here are some more hellish workspaces:
Here's what we noted about the hellish workspaces:
- Motivational posters are demotivating
- Boss has a nice office, we're playing sardines
- Desks with cut-outs hurt your knees
- Noise coming from sales and support areas
- Broken aircon - it's either too hot or too cold
- Distracting music or TV
- No wall space
- Flickering lighting, no natural light
- Individual offices or cubicles
- Placements are back-to-back, cramped
- Debris, cables, clutter, uncollected rubbish
- Dirty offices, smelly
- Distributed teams
- Depressing colours
- Not enough power sockets
- Noisy printer or photocopier
- Wrong level or non-adjustable desks
- Placed in a corridor
- No meeting rooms
The second workspaces we built were from heaven. We tried to rectify some of the problems in the hellish workspaces.
Here's what we noted about the workspaces from heaven:
- Straight-sided tables
- Spacious break-out areas
- Mobile whiteboards
- Projector, video-conferencing facility
- More space
- Lava lamps
- Big screens
- Floor-to-ceiling windows
- Pair-programming islands
- Meeting rooms with glass walls
- Plenty of storage space
- Good coffee machine, water cooler
- Table football
- Sound-proofing
Sites worth checking out:
1.
www.informativeworkspace.org2.
www.fairlygoodpractices.comTags:
informative workspace
Links to this post
XPDAY2006: Experiments in Agile Estimation
Experiments in Agile Estimation was a workshop, facilitated by
Mike Hill,
Nils Haugen and
Stein Grimstad, that explored planning poker as a group estimation technique. For the first experiment we had to estimate
user stories on our own. It looks like I have a tendency to be optimistic. Perhaps I'm too
courageous? Or just stupid? Don't answer that! The second experiment explored how effective planning poker was with respect to individual estimation.
The statistical evidence collected to date (as part of the research conducted by
Nils and
Stein) was not presented very clearly (take a look at this
pdf). But they observe a tendency to overestimate when using planning poker.
Nils asked an insightful question: Is it actually a tendency to finish under the estimate? Looking at the results from an analysis of the code written on the projects used in the research sample, work estimated with planning had, on average, twice as many deleted control statements (perhaps indicating an effort to do the simplest thing) and twice as many deleted out-of-class references (perhaps indicating an effort to reduce coupling). So, does planning poker positively affect the quality of implementation? I'm not convinced.
Planning poker is definitely fun, and lets face it, estimation is something we all hate doing. It gets everyone involved and talking face-to-face. And the group discussions draw knowledge from many sources, help to explore uncertainties and reveal more hidden detail before estimating. Planning poker incorporates participatory decision making and is effectively
consensus-driven. Reaching an estimate as a group gives developers a sense of comfort as they collectively own the estimate and it also gives them more confidence in the estimate. The technique can feel cumbersome when you first start doing it. However, once people get used to it the actual overhead is very low. But be careful that discussions don't take too long.
One person at the session thought the use of cards was unnecessary. I disagree. Always use the cards. They make it clear that everyone is engaged and participating and it helps retain a structure to the proceedings. Without structure, group discussions can quickly become wasteful.
Originally, we used index cards with numbers written on them. Now we're using nice glossy cards that
Conchango were handing out at the
Agile Business Conference. We're using ideal pair days as estimation units (and not
story points) so the only cards we use are 0, 1/2, 1, 2, 3 and ?.
User stories that get a ? are split into smaller stories.
Here's how we do it:
- The product owner reads the user story aloud adding further details as necessary.
- The team asks questions about the user story.
- As the discussion tails off, the facilitator says "Ready" and asks "Do you have enough information to estimate this story?".
- When everyone responds "yes", the facilitator says "Steady. Select your estimate." Each person then selects their card and holds it out in front but does not reveal the number to the rest of the team.
- When everyone is holding a card out, the facilitator says "Go" and everyone reveals their estimate by turning their card around to face the team. (Simultaneous revealing of estimates might reduce an anchoring effect where people who reveal their estimates early influence estimates from others in the team.)
- The facilitator asks the people with the lowest and highest estimates to explain their selection.
- The facilitator says "Lets do another round". Go back to 4.
- Loop through points 4 to 7 until all the estimates converge at a single number.
Mike Cohn describes planning poker in the sample chapter,
Techniques for Estimating, from his book
Agile Estimating and Planning
.
Tags:
planning poker,
estimation
Links to this post
Ken Schwaber talks about agile quality
Ken Schwaber talks about
Agile Quality: A Canary in a Coal Mine.
If you get told to deliver specific functionality by a specific date that is impossible to attain without sacrificing quality, just
say no. Remind the person who is effectively telling you to cut quality, that
the software you're developing is a corporate asset. Do the right thing - don't build crap corporate assets.
Tags:
scrum,
quality
Links to this post
Running tested features
Ron Jeffries talks about
running tested features. He's also recently blogged about it
here and the original article is
here.
We're tracking
running tested stories within each iteration.
Tags:
running tested features,
burnup chart,
big visible chart
Links to this post
A pair checks in code that breaks the build. The build interrogates
subversion to identify the commiters and the
usb missile launcher locks on and launches. The missile lands on the desk of the pair, or bounces off a head, notifying them that they've broken the build. If only that could really be automated.
Tags:
extreme feedback device,
feedback
Links to this post
Are We Nearly There Yet? looked at some of the reasons why tracking is often not done particularly well.
Ivan Moore covered the important concepts to which he added some of his own experiences and observations. For example, what you need to complete for a
user story to be really
done; the pros and cons of
story points versus ideal time versus real time; using different estimation units for release (relative magnitude) and iteration planning (time-based); why velocity is the total estimates of the
done user stories rather than the sum of the actuals.
I was expecting a more advanced session, in particular I was hoping to discover some new information radiators for tracking, but the session covered only the basic tracking techniques and
burn charts. I think beginners would find it an informative session so perhaps it should've been in the 'Introduction to Agile' track rather than the 'Peopleware' track.
The subject itself is very important and lots of people clearly thought that. There were too many attending this session for the room allocated. It was a squeeze. I would like to see an extended session that includes some exercises to allow people to experience estimating using different units, and tracking actuals rather than original estimates and the impact that has on velocity. I'd also like to participate in a brainstorm to invent some new tracking information radiators.
I came out of the session with one useful tip. I usually record obstacles on index cards placed on an 'Obstacles' wall. But I liked
Ivan's tip about user stories that are blocked. We're experiencing problems with dependencies on other teams who are not agile. Every time a
user story gets blocked by another team we now stick a pink index card over the story card saying 'BLOCKED' in big letters. This makes it very obvious to our
product owner and stakeholders just how difficult it can be for us and how we're slowed down by these dependencies.
Tags:
xpday,
tracking
Links to this post
Gus has started a
wiki. Check it out and watch it over the coming months. It's going to say some important stuff about the state of agile today.
Links to this post
