Energized Work | agile in action

Sitemap on the wall

2010-02-04T23:02:00.000Z

Petition against recurring Government IT incompetence

2010-02-02T15:31:00.003Z

Isn't it about time we started calling the civil service and the Government to account for the repeated failures and wasted money in Public IT projects?

Don't delay! Sign the petition to the PM.

Integration Testing: The Story Continues

2010-02-01T16:06:00.005Z

Over the past few months I've been reading the 'Integration Tests Are A Scam' serious of articles by J.B. Rainsberger and following some of the responses to it such as this one by Steve Freeman. I put in my 2 cents a few days ago which I've reproduced here:

Interesting series of articles & comments. I also read Steve Freeman’s article in response to the same topic. It’s got me thinking about how we work and I thought I’d take the time to describe it here.

You define an integration test as “… any test whose result (pass or fail) depends on the correctness of the implementation of more than one piece of non-trivial behavior.” We have many such components that exhibit such non-trivial behaviour in the products we create, many of which are not developed by us. And we have integration tests to verify they work. I’m not just talking about 3rd party libraries and frameworks here, I’m referring to the whole system: caching layers. load balancers, DNS servers, CDNs, virtualization etc. When we build software it only becomes a product or service for our users when it has been deployed into a suitable environment; an environment that typically contains more than just the software we have written and packaged. Since our users’ experience and perception of quality result from their interaction with a deployed instance of the whole system, not just their interaction with the software at a unit level, we have come to value end-to-end integration testing. I believe there’s merit in testing these components in symphony and will attempt to clarify what kind of integration testing I’m talking about.

For a given piece of functionality we write an executable acceptance test in human readable form (for web projects we typically use some domain-specific extensions to selenium, for services we have used FIT and it’s ilk, sometimes we roll our own if there’s nothing expressive enough available). We run it against a deployed version of the application (usually local though not always) which typically has a running web/application server and database. The test fails. We determine what endpoint needs to be created/enhanced and then we switch context down into unit-test land. A typical scenario would involve enhancing a unit test for the url mappings, adding one for the controller, then one for any additional service, domain object etc. When we’re happy and have tested and designed each of the required units we jump back up a level and get our acceptance test to progress further. The customer steers the development effort as he sees vertical ‘slices’ of functionality emerge. The acceptance test is added to a suite for that functional area. The continuous build system will then execute that test against a fully deployed (but scaled down) replica of the production environment, with hardware load balancer, vlans, multiple nodes (session affinity) and so forth. Any additional environmental monitoring (e.g. nagios alerting) is also done as part of this development effort and is deployed into the test environment along with the updated code.

Setting up the infrastructure to do this kind of testing takes investment, both initial and ongoing. The continuous build needs to be highly ‘parallelized’ so you get feedback from a checkin in 10 mins or less (we’re heavy users of virtualization, usually VMWare or OpenVZ). The individual acceptance test suites need to be kept small enough to run quickly before check-in.

Benefits of this approach

The continuous context-switch between acceptance test and unit test is key to our staying focused on delivering what the customer actually wants.

The customer has multiple feedback points that he can learn from and use to steer the development effort.

It confirms that the whole system works together – networking, DNS, load balancing, automated deployment, session handling, database replication etc.

We create additional ‘non-functional’ acceptance tests that automatically exercise other aspects of the system such as fail-over and recovery.

Upgrades to parts of the system (switches, load balancers, web caches, library versions, database server versions etc.) can be tested in a known and controlled way.

We’ve caught a number of integration-related issues using this approach (a few examples: broken database failover due to missing primary keys, captcha validation not working due to a web cache not behaving correctly, data not persisting because one database server had the wrong locale) and stopped them before they have reached our users. We have used the feedback as a basis for improving our products and their delivery at a system level.

OK this reply has now become far too long :-/ It would of course be good to discuss this in person sometime :)

J.B.'s taken the time out to respond and it seems that there's a lot of common ground. Maybe there's a language problem here in developer land? Do we need some clear common definitions in this area?

Don't aim at the target

2010-01-24T23:10:00.004Z

Without numerical measures we wouldn't know what to do. The problem is, when numerical measures are used as targets they cause people to think their sole purpose is to achieve them, usually to the detriment of everything else. When managers own the targets and use them to force performance they bring out the wrong behaviors. People cut corners to meet the targets. And targets are everywhere. We blinker ourselves to everything except our targets and forget about the real needs of users. In pursuit of our targets we make local optimizations that are suboptimal for the throughput of the whole system, the wider organization.

Measures should reflect the true purpose of the people doing the work, which is to improve service and quality and satisfy users, and should therefore measure the improvements directly experienced by users. These people are in the best position to decide how to improve quality and performance and they should own the measures and use them to understand their work as a system. As part of a plan-do-check-act cycle, they should study the actual results of changes aimed at improvement, comparing them to expectations, analyzing the differences to determine cause, and then identify further opportunities to improve the system.

Managers shouldn't use their measures as targets to control our performance. Instead, we should use our measures to continuously improve how we work so that our system performs better.

Bad posture

2010-01-23T18:06:00.003Z

Jeff Patton recently tweeted:

“I see agile process practiced with waterfall posture. By posture I mean the values, principles, and thinking processes with which you approach software development.”

I like this.
It's a simple way to explain many of the things I see.
'Posture'.

What's distinctive about Lean Thinking and where is it going

2010-01-19T20:54:00.003Z

At the UK Lean Conference, my brother Marc Baker talked about Lean Thinking, how it has developed into a complete business system and where it's going. He also shares some insights from lean transformations he has been part of in Healthcare.

Lean Software and Systems Conference in Atlanta

2010-01-16T14:35:00.003Z

David Anderson invited us to speak at the first Lean Software and Systems Conference in Atlanta from April 21st to 23rd 2010. We'll be talking about our evolving 'system' for software product development, which David saw when he visited us at BSkyB, and more. That was nearly two years ago. Since then we've continued to develop the approach and techniques, applying it more recently on a project with a couple of consultants from the Womack and Jones crew at the Lean Enterprise Academy.

Here's the abstract for our session:

Product Development in the Land of the Free
The Test-driven Organization

Creating and sustaining a 'system' for effective product development is neither easy nor commonplace. If we were to pull together the lessons we've learned from eXtreme Programming and Scrum with systems approaches such as Lean Thinking and the Theory of Constraints to build such a 'system' what would it look like? Where would we start? How would we organize ourselves? And what would be our approach?

The fact that so many information technology projects are still failing tells us that we should be doing something very different. This session will explore some of the things we've been doing beyond the agile comfort zone to improve the effectiveness and throughput of product development and realize business agility.

Invite us around for a cup of tea

2010-01-15T14:33:00.007Z

Since we won the Gordon Pask Award we've been wanting to get out and about to meet people, visit organizations or usergroups, see how people are working, understand the problems overcome and the problems still faced, and learn some new things.

We're happy to share our experiences through an informal 2-hour get-together, be it a brown-bag session, a meeting during office hours or an after-work gathering. We'd welcome the opportunity to answer questions, talk about a topic of your choosing, participate in a discussion, provide a sounding board, or offer advice. And we're more than happy to consider other suggestions.

This is without obligation on your part and free of charge if you're located in London. If you're outside London we'll probably ask you to cover our travel costs.

If you think this would be useful to you, your team or your organization please email simon at energizedwork dot com.

Reports are waste and a reason for poor decision-making

2010-01-14T11:34:00.022Z

Myron Tribus said:

"Managing a company by means of a monthly report is like trying to drive a car by watching the yellow line in the rearview mirror."

Periodic progress reports are a symptom of hierarchical thinking. They make everybody 'look up' at managers rather than 'out' to users.

Progress reports don't tell you what's going on. They tell you what people want to tell you. And decisions based on such incomplete information are risky and likely to be poor. Producing reports is waste; it’s not adding value.

As John Seddon says "reports are substitutions for action". To really know what's going on you must go see the real thing for yourself. And do it regularly. Talk face-to-face with the people doing the work and observe the actual process at the actual place to obtain actual data. Learn from each visit and make your decisions on the facts you have gathered yourself.

Getting past design to design thinking

2010-01-10T20:53:00.007Z

I previously mentioned that we've been applying iterative development to grow better user experiences so I found the following words and the video particularly interesting.

"Instead of starting with technology start with people and culture. If human need is the place to start then design thinking rapidly moves on to learning by making. Instead of thinking about what to build - build in order to think. Prototypes speed up the process of innovation because it's only when we put ideas into the world that we really start to understand their strengths and weaknesses. And the faster we do that the faster our ideas evolve.

Instead of seeing the primary objective as consumption, design thinking is starting to explore the potential for participation. The shift from a passive relationship between consumer and producer to the active engagement of everyone in experiences that are meaningful, productive and profitable."

Tim Brown of IDEO urges designers to think big:

Be your users' best friend

2010-01-10T18:08:00.022Z

Frankly I'm tired of manifestos. It's not that any of them are bad. They are well intentioned and usually well formed but they're too open to interpretation. And I, like anyone else, have my own interpretations. That said I'm grateful to Alisatir Cockburn and those involved for writing down a manifesto for users.

UX has always interested me and, for the last year or so now, we've been working with an increasingly user-focused approach applying iterative development to grow better user experiences. I've wanted something simple that I could chant in my head to remind myself that we're here to 'please' users and the manifesto spurred me to action. So, here's my de-manifesto'ed user chant:

As a user I want a product that:

solves my problems
works reliably
evolves as my needs evolve
enables me to work effectively
lets me see my job getting done
I enjoy using
occasionally delights me

Speaking at London QCon

2010-01-08T11:03:00.008Z

We've been invited by Jesper Boeg to speak again at QCon London. Here's the abstract for our session:

Product Development in the Land of the Free
The Test-driven Organization

Creating and sustaining a ‘system’ for effective product development is neither easy nor commonplace. If we were to pull together the lessons we’ve learned from eXtreme Programming and Scrum with systems approaches such as Lean Thinking and the Theory of Constraints to build such a ‘system’ what would it look like? Where would we start? How would we organize ourselves? And what would be our approach?

The fact that so many information technology projects are still failing tells us that we should be doing something very different. This session will explore some of the things we’ve been doing beyond the agile comfort zone to improve the effectiveness and throughput of product development and realize business agility.

Specialists should become more

2009-12-24T17:36:00.010Z

In my ideal team anyone can do anything. Sadly it's just not realistic. Some skills are just too specialized. That said, if you need the specialized skills get a specialist in the team and avoid sharing some centralized service. Don't worry if the specialist is not utilized 100%. That's a good thing! If he has the right attitude he will muck in, contribute in other areas you did not anticipate, and he should use the opportunity to acquire complementary and even new skills by working with and learning from the rest of the team. And of course, it goes without saying that he should be helping others acquire a level of competence in his specialized skillset to build resilience into the team.

Curse of the specialist

2009-12-19T18:12:00.011Z

If you're a specialist then you probably have some expertise that enables you to objectively state a case for doing something or doing something in a certain way. And you should be able to persuade others that it is the right thing to do. Being the expert doesn't give you the right to make unilateral decisions in a team. Give your knowledge freely. You have an obligation to help people learn from you. Be approachable and share.

If you go-it-alone you're doing damage.

Intrinsic motivation

2009-12-10T12:15:00.007Z

Money is important in this day and age. But money doesn't motivate people to do their best. Watch the video. Even better read some Deming.

I don't do my best work because I'm getting paid well. I do things because I think it matters, I enjoy it, I find it interesting and I believe it's part of something important.

At Energized Work people are paid a wage but they are rewarded intrinsically. We create Ba - a time and space where creative energy flows, existing knowledge is shared and new knowledge is created. People are living freely in this environment, in this culture. This helps them realize the elation in directing their own working lives, continuously improving at something they belibeve matters, and in doing something in the service of something larger than themselves. We'll be doing more in the new year to focus this creative energy.

Budgeting bunkum

2009-12-09T23:30:00.008Z

Despite the UK Government issuing it's new budget today - oh utter joy, btw - this post was motivated by IT budgeting experiences.

I consider budgeting to be waste.

A budget is based on assumptions and estimations and therefore, without constant refinement, which seldom happens, it gets out of date fast. And the whole process of arriving at the budget amount is shamefully stupid and entirely comical! It goes something like this ..

Someone gets to spend an inordinate amount of painful time (living the myth that it’s possible to know everything at the start) trying to calculate the amount of money needed to deliver 'whatever'. That amount is submitted, consolidated and rolled up into department, division, etc, and ultimately company figures, undergoing a protracted review process enroute that typically results in the amount being summarily cut. Of course, this is all a silly game and everyone knows how it's played. The someone, to ensure he receives the amount he feels he needs to get the job done, exaggerated the amount in the first place. He purposely over-budgeted in his submission in anticipation of budget cuts. The reveiwers know this. And the someone knows the reviewers know and .. *sigh* What starts out involving the operational realities soon becomes a purely financial planning exercise that is divorced from the operational realities. The futility of it all.

It gets dafter. Ever heard of people rushing to spend the remaining money from this year's budget before the year runs out so they won't suffer budget cuts next year? WTF!

This all works so well, right! There's got to be more effective ways.

Being cost effective

2009-12-07T23:25:00.002Z

Forget about economies of scale. Reduce complexity.

Speaking at the Lean Software & Systems Conference

2009-12-01T11:43:00.004Z

We'll be speaking at the Lean Software & Systems Conference in Atlanta in April 2010. Not sure what the session will be about yet.

New blog url

2009-11-27T13:33:00.002Z

If you follow this blog we'd prefer you to use the new address - http://blog.energizedwork.com. However, we'll continue to support http://www.agileinaction.com (and http://www.think-box.co.uk/blog) until further notice.

Pirate Rob on Grails Selenium RC

2009-11-21T11:50:00.005Z

Pirate Rob gave a talk last night at London Groovy & Grails User Group about testing Grails applications with the Selenium RC plugin.

Backstage at Boffoonery

2009-11-04T19:07:00.011Z

Finally Boffoonery happened last night and it was absolutely spiffing fun. I'm so glad we sponsored it. It was a triumph and a wonderful tribute to Bletchley Park and to those who worked there. Congratulations to the cast, especially Johnny Ball for his performance during the quiz and for reminding me of the fun I had as a child watching his TV shows. Jason, you can be proud of what you've done here and you thoroughly deserve that big cigar! Clive Flint was a superstar and came to the rescue at the last minute to take some wicked photos on the night. It was cool to go backstage beforehand and impose as the stars chilled out. And it was great to talk with Simon Greenish at the bar afterwards. Thank you again for your invitation to Bletchley Park. We'll be up there pronto.

Backstage with the girls
Originally uploaded by clive.flint

Robin Ince and Johnny Ball
Originally uploaded by clive.flint

Maggie Philbin and Jason Gorman
Originally uploaded by clive.flint

Some of the cast
Originally uploaded by clive.flint

Thanks Jason for the Commutineer coverage especially the centre-spread in the programme (below). We're continuing to improve the Web site and we'll continue to do so beyond the official launch later this month. So don't wait until then! If you're dallying with the daily commute please share your experiences, observations, encounters at commutineer.com. Be naughty. Or nice. What you say may be useful to other commuters. And we'd love more feedback. We plan to hook it up to Twitter too. So if you're tweeting about your commute please tag it #commutineer.

How we use stories

2009-11-02T13:15:00.010Z

All our work items, both user-focused and technical, are stories framed in the context of a user interacting with the product. Each story represents a distinct, visible and testable piece of work that can be delivered independently to realize some value. Stories exist at many levels of specificity and never convey solutions. For example, at a point in time it's sufficient to use an ambiguous story to describe an interaction as simply an activity a user engages in using the product. At some time later, typically when detail starts to matter, smaller stories are written to describe that activity in terms of more specific tasks the user performs with the product.

Stories are written on index cards measuring 6 by 4 inches. A description of the user interaction is written in as few words as possible on the front of a card to provide a brief outline. This provokes conversations to reveal and understand the details, which are captured as acceptance criteria on the reverse side in the language of the user. The physical card serves as a token, exchanged amongst the team when different people work on the story. It also acts as a physical flag that shows others what's in progress and a story's history in terms of the feedback obtained so far from testing, user experience, etc. Different colored index cards are used for different types of user:

1. Business and end users

White cards describe stories written for business and end users.

Green cards describe user experience stories that need to be completed ahead of time and in just enough detail, e.g. using low fidelity prototypes or design mock-ups, to facilitate an iterative approach and provide useful input to the corresponding white cards.

Pink cards describe defects from the users' perspective and include the steps to reproduce on the back. We never debate whether something is a defect or not, we just ask the product owner.

2. System and technical users

Yellow cards describe stories written for technical users, e.g. a system administrator operating and supporting the product, or for discrete system engineering work such as scalability and resilience.

3. Technical debt

Blue cards describe stories written for developers, who are considered users of the system at an engineering level. They describe technical debt in system and software terms and include acceptance criteria on the back so the developers know when they're done.

The size of a story isn't important until it's planned and prepared, ready to be implemented.

Developing the product iteratively

Using iterative development we progressively refine and extend functionality already delivered. Over time a user task is sometimes revisited by any number of stories. Whenever possible we use a green card to build a paper prototype that allows us to evaluate interaction designs with users before developing any software. The first white card typically delivers very basic functionality that allows users to perform the task using the product. Feedback from users validates our assumptions and often initiates a new story to enhance the functionality or improve its performance and ease of use. Every story aims to improve the experience for the user based on their feedback to enable them to perform the task more efficiently or effectively.

By delivering a minimal version of functionality early and then evolving it in response to user feedback, we remain receptive to discovery and keep our options open rather than committing prematurely to a specific user experience. This way we invest more wisely to deliver exactly what the users wants, and no more.

Timeouts and retrospectives

2009-10-22T00:11:00.003+01:00

We use timeouts and a couple of different retrospectives to drive improvement. Stop-the-line events like Pomodoro timeouts and Pomodoro retrospectives happen spontaneously within the team to solve problems immediately and produce small continual improvements. We also use a monthly retrospective for the product stream to reflect on how it's working and conceive bigger, more strategic improvements.

Pomodoro timeout

One of our norms is that anyone can call a timeout. The team calls timeouts frequently, usually more than 1 a day; they seldom last 25 minutes and if they need longer they just run another Pomodoro. People huddle in the bullpen, sometimes around a whiteboard, to discuss something within the remit of the team and collectively decide what to do. Whether the purpose is to discuss a technical issue and define a set of spikes to prove the way forward, explore options to get around an obstacle, or investigate a process issue, the timeout often creates opportunities to make improvements.

On-demand Pomodoro retrospective

When something extraordinary happens the team runs a Pomodoro retrospective in 25 minutes, as soon as possible after the event, to find the root cause and agree 1 specific and clearly defined action that can be taken immediately to prevent it reoccurring. We like to use the 5-whys technique but we also use other activities (within the format - brainstorming, affinity mapping, dot voting, decide what to do) depending on what had happened. The retrospective is always done standing up to keep people focused and energetic. Most of the time the retrospective concentrates on events that the team could have controlled or avoided. However, sometimes it investigates problems in the product stream that were outside the team but nevertheless impacted them, in which case appropriate people from the stream also participate.

Monthly retrospective

Once a month the facilitator runs a structured retrospective for the product stream (that involves setting the stage, gathering data, generating insights, and deciding what to do, close). Everyone in the team attends, including the technical mentor, as does the business sponsor, product owner, team leaders from the business users plus a handful of their staff, and other people from the various business disciplines within the stream. The purpose of this retrospective is to step back and look at the big picture, including any external factors that have affected the stream, and identify any trends. We challenge how we currently work and try to get beyond the obvious to discover transforming ideas that would make the product stream more effective.

Product stream

2009-10-21T23:19:00.037+01:00

A description

Think of a product stream as a small company working exclusively on a product and delivering features that excite users to maximize profit and growth. The stream invests in its relationship with users and is set up to compete on the basis of speed. It has everything it needs to conduct business, from concept to production to operational support, and unlike a project it persists as long as the product is in service. It includes a dedicated and diverse technical team that is actually part of the business and helps them use software more effectively. It self-organizes for optimum delivery and minimum risk, and produces flexible software that responds as the business learns from user and market feedback.

Everyone in a stream is located together in the same place and works full-time to develop a common understanding of what users value, and to achieve a shared vision for the product against which success is measured. People in the stream collectively own the product and share responsibility for achieving results. Cash flow is key. Everyone understands the financial consequences of decisions and actions, or lack thereof, so people think in terms of delivering value to users as quickly as possible and cost effectively. Only people in the stream work on the product; in a transparent environment they collaborate intensively, communicate honestly and keep the right information visible so that informed decisions can be made at the right time.

A stream has 4 key roles that together provide entrepreneurial leadership and unified direction:

The business sponsor is a product champion and a visionary. He owns the budget and is ultimately responsible to the company for the overall product stream and is accountable for its results. With empathy for users, a deep knowledge of the market and an understanding of the stream's capabilities, he defines the strategy and makes business decisions quickly.

The product owner is the sponsor's right-hand man and also a product champion. Synthesizing the needs of different users (and stakeholders), he focuses delivery on evolving features in response to their feedback and changing market conditions to facilitate business agility.

The technical mentor is a master craftsman with business acumen, extensive knowledge and vast experience in delivering high-quality software products to market. He coaches the technical team on a journey that they cannot take on their own, using earned trust to show them new skills, techniques and thinking processes.

The facilitator actually leads the technical team with passionate support and faith in their work; he manages the budget and is responsible for results. Facilitating without detailed or coercive direction, he lets people self-organize, steering with a light touch. He helps the team function effectively by providing everything it needs, driving consensus decisions, removing obstacles that impede delivery and creating an environment in which peoples' potential is developed based upon mutual respect and cooperation.

The technical team comprises all the technical skills it needs to develop software for production and operational use. There are specialists such as testers, system administrators and designers, however everyone works to acquire more general skills to build resilience into the team. A stream is always learning. It works continuously to eliminate waste and improve through reflection and experimentation. Creative energy flows, existing knowledge is shared and new knowledge is created as everyone works with shared responsibility to improve quality, remove causes of failure and find better ways of working.

Over time the composition of a stream varies to suit the needs of the product. However, it retains the skills and expertise it needs to deliver the highest possible quality and service to users. The business sponsor, product owner, technical mentor and facilitator are always present.

Shorten the value stream by bringing it inside

Our goal, starting and ending with the user, is to shorten the value stream and encapsulate it within the product stream. We aim to seize a crisis and initiate kaikaku events to eliminate some of the more obvious non-value adding steps. We collocate and remove dependencies to eliminate handoffs between teams, co-ordination overheads with other teams; waiting around for information, approval, access to business people or shared resources; chasing people in different locations for responses. We favor open-source software rather than relying on core teams producing platforms and infrastructure systems, and we remove all other dependencies by absorbing skills and responsibilities into the product stream. For example, in a recent stream we had established a cooperative partnership with the company managing the datacenter where our production environments were hosted and they agreed to implant a system administrator into the stream to work as a member of our technical team.

Within the product stream, the necessary conditions are nurtured to enable frequent delivery of features to users, at a predictable and reliable rate. Work in progress is limited to the capacity of the technical team (minus some slack) to avoid people burning out and they always stop to fix problems before continuing. Working at a sustainable pace, they even out the arrival of work by making stories approximately the same size, use pull scheduling and release every week to create flow.

The technical team operates all the environments, including production. They automate as much as possible and manage the monitoring, alerting and capacity planning. Consequently they develop expertise in how the product runs, which enables them to diagnose problems more effectively. They also get to innovate in the 'system space' to meet business and user needs. They select the technology stack, deploy the product to the production environments, and they operate and support it, 24/7. If they do something to break production, they feel the pain straight away. They work hard to prevent that happening by delivering high-quality, well-tested software and, with end-to-end knowledge and full access, the team works continuously to eliminate complexity and duplication across the system, and to reduce the overall maintenance and support effort.

Rolling ownership of stories through the team

2009-10-20T14:50:00.004+01:00

We added rolling ownership to our pair-programming back in April 2008 and we've been using it since.

Rolling ownership enables as many people as possible to get involved in delivering a story. When a new story is started, someone volunteers to own it and another person volunteers to pair in. They work on the story until lunchtime. After lunch, the pairs swap. For each story in progress, the owner moves off the story passing ownership to his morning partner and a new volunteer steps in to pair. This rolling effect allows tacit knowledge of the story to be retained across pair-swaps. When each person owns a story they add their initials to the right-hand side of the card. Repeated everyday, most, if not all, of the team play a part in delivering each story. We've found that rolling ownership facilitates shared learning and decision-making, helps spread knowledge of the product around the team, and the pair-swaps and shifting ownership keeps people communicating.