Energized Work | agile in action

Effectiveness of a real product stream

2010-03-07T15:48:00.028Z

I've pulled together some data for the first year of a product stream we created and plotted it as charts for throughput, rework and effectiveness.

The first chart shows the weekly rework. I've talked about rework previously so I won't cover it again here. The blue line indicates the remaining technical debt and the blue bars the repaid technical debt. The pink line indicates the remaining defects and the pink bar the fixed defects. Week by week, it can be seen that defects were fixed as soon as they were discovered to reduce the remaining defect count to zero. Also the technical team continuously repaid technical debt to keep the remaining amount of rework small.

Rework
Originally uploaded by energizr

The second chart shows the amount of throughput every week.

Throughput
Originally uploaded by energizr

The peak at week ending 18/12, without any throughput during the 8 preceding weeks, demonstrates a flush of inventory amounting to 104 cards and corresponds to the alpha release of the product. In the rework chart, a small increase in fixed defects can be observed during the same week. Inventory again builds up for two weeks, as improvements are made to the automated deployment system, until the next peak at week ending 15/01. At which point 48 completed cards are flushed. Releases then occurred every week and while some variation is observed the throughput remained stable.

To improve the performance of the product for the beta release during week ending 26/02, 7 technical debt cards were completed. As the system experienced more rigorous use by editorial users, 12 defects were fixed plus a further 8 the following week due to increased traffic. The official launch was completed in the week ending 18/03. During that week some data inconsistencies were encountered following migration from the old content management system, which resulted in 9 defects. In response to traffic loads the load balancers were tuned with 5 technical debt cards. This effort continued the following week with a further 8 technical debt cards and 7 fixed defects as traffic increased to approximately 180 million page impressions and 3.7 million unique users per month with an average page weight of 2Mbytes. Further peaks in technical debt of 20, 16 and 10 can be seen during the weeks ending 06/05, 17/06 and 24/06, respectively. This work concentrated on the expansion of the product with reconfiguration of the production environment to support additional channels.

It's worth me recapping on effectiveness. Effectiveness is used as a measure of the product stream's ability to sustain throughput and minimize failure demand, which allows capacity to focus on meeting value demand. It was inspired by the First-Time-Through (FTT) measurement used in Lean manufacturing to measure the effectiveness of a cell's standardized work as a percentage of product made without any need for rework or scrap.

The effectiveness of the product stream is defined as:

Effectiveness = ( Throughput - Rework ) / Throughput

where

Throughput = the number of cards released to production (excluding completed rework)

and

Rework = the number of technical debt and defect cards in inventory and work-in-process

The final chart shows the weekly effectiveness of the product stream.

Effectiveness
Originally uploaded by energizr

The lows at weeks ending 29/01, 25/03 and 01/04 can be attributed to marked dips in throughput. At 29/01, 12 cards were queued as inventory whereas a small increase in the amount of remaining rework was present at 25/03 and 01/04. Clearly the product stream is most effective when the completed rework was small compared to the throughput and was enough to keep the remaining rework small compared to the throughput.

Come and see us at QCon London on 11th March

2010-03-07T00:35:00.053Z

Come and hear us talk at QCon London. Our session is at 3pm on Thursday 11th March in the Agile Evolution track. We'll be talking about Product Development in the Land of the Free.

Product Development in the Land of the Free
Originally uploaded by energizr

Abstract:

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 what would such a system 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.

PS. Thanks to Jesper for inviting us along.

Visual Hospital

2010-03-05T19:17:00.006Z

We've been working with the boys from Visual Healthcare Solutions (who are faculty members at the Lean Enterprise Academy) to create a touchscreen solution called Visual Hospital, which supports the methods they talk about in their book Making Hospitals Work. It's been a lot of fun using an iterative approach to building the interaction design with the users.

We're very excited to collaborate with these lean consultants as they continue their work in healthcare.

Inevitable and avoidable rework

2010-02-26T11:23:00.006Z

Without really thinking about it until now, I've been seeing two types of technical debt. The first is the quick solution implemented with dirty code. I consider this to be irresponsible. That's not to say I won't do it, just that if I decide I should do it I make sure the necessary people understand the consequences and that it's an irresponsible action to take.

The second is a natural byproduct of emergent design and YAGNI(yet) decisions. It's the debt that surfaces when a system outgrows implementations resulting from previous decisions, which were the right ones to make at the time based on the information available (because they did not compromise quality or the health of the code in any way). Irresponsible debt creates avoidable rework; it's failure demand. It's bad, it smells and it needs to be cleaned up because, if left to fester, it's going to slow us down and divert capacity away from meeting the value demand.

The debt that surfaces because the system is maturing creates inevitable rework. It's necessary to do this rework on a regular basis to keep the emergent design relevant, the code habitable, to prevent obsolescence, perhaps increase reuse, and reduce risks and medium to long-term costs. I think most people try to roll this debt into feature cards and that's the right policy. We prefer to do that if we can. However, we've become too good at writing cards to be less than 2 days (which helps smooth the flow) and sometimes it's not possible to absorb inevitable rework into a feature card and keep it under 2 days (the way we like it). And of course, sometimes, the rework just doesn't relate to any features, e.g. upgrading to the latest Grails framework. So this gets written on a blue card. By definition this is failure demand too. But that's harsh, don't you think? I have a weird take on this because I insist that the system is recognized and treated as a stakeholder, and as such it values certain things and makes its own demands. One of the things it values is to be kept healthy. But I'm not hung up on this rework being classified as failure demand providing it's being managed effectively.

As I mentioned in my previous post, completing some inevitable rework on a regular basis (and assuming you're not being irresponsible ;) helps reduce the remaining rework. We can see this in action in the chart below.

Rework
Originally uploaded by energizr

The blue and pink lines show the remaining technical debt and defects that are either work-in-process or queued inventory (i.e. completed but not released). The blue and pink bars show the technical debt that has been repaid and the defects that have been fixed. Think of these bars pulling the remaining rework down keeping it small and preferably fairly steady. And, of course, assuming there's throughput satisfying the value demand then the team is effective.

It's useful to track the remaining technical debt and defects in statistical process control charts. The natural process limits help to distinguish signs of system instability from normal variation. When the limits are breached investigate what's happened to understand how the system may have changed. Watch for trending beyond the breach as it's likely to reveal more information to help you. Use these events to identify improvements.

Technical Debt SPC
Originally uploaded by energizr

Defects SPC
Originally uploaded by energizr

(Incidentally, the process limits were calculated between weeks 7 and 14 because week 6 saw the system change. Up to the end of week 6 all the software completed became queued inventory. This was then flushed to throughput and released, enabling a weekly release from then on.)

A simple measure of effectiveness

2010-02-24T15:49:00.281Z

In the Lean manufacturing world there's a measurement called First-Time-Through (FTT), which monitors whether a cell is making products right the first time. It's a measurement of the effectiveness of the cell's standardized work and shows the percentage of product made without any need for rework or scrap.

FTT = ( Total units processed - Rejects or Reworks ) / Total units processed

If the standardized work is adhered to, the product will be made right first time and FTT will be 100%. However, flawed materials, faulty components and operator error all contribute to rework and scrap.

Who cares about parallels between manufacturing and software development? I was just interested to read about FTT because I've been thinking for a while now about the effectiveness of software teams ... at an operational level, let's say. I've long considered an effective team as one that is able to sustain throughput (i.e. the number of cards released to production that deliver value) while fixing defects immediately and repaying technical debt to keep the amount of rework small.

I consider technical debt and defects to be rework, and technical debt to be a natural byproduct of software development. It stems from earlier decisions, based on what we knew at the time, and requires attention later when the system has outgrown the outcomes of those decisions. It is necessary rework that keeps the emerging design relevant and the software healthy and habitable, reducing risks and medium to long-term costs. Defects are basically mistakes. They happen. How we create software determines whether we have a small and manageable amount of rework or a crippling amount of rework. If we're responsible, skilled and bake quality into code we can minimize rework to technical debt and occasional defects. If we're irresponsible and cut corners, or we're rubbish and write crap code, then rework can become so large that the only viable option is to cancel or start again.

Technical debt requires careful management and continuous investment while defects should be fixed as soon as they are found. A proportion of a team's capacity is therefore always expended doing an amount of rework. That's a good thing providing:

the completed rework is small compared to the throughput so that capacity mostly focuses on value demand, and
the completed rework is enough to keep the remaining rework small compared to the throughput, thus minimizing further failure demand.

(Throughput excludes repaid technical debt and fixed defects that went live).

On a weekly basis then, the throughput in relation to the remaining technical debt and defects might be a useful measure of a team's effectiveness.

Effectiveness = ( Throughput - Rework ) / Throughput

where

Throughput = Number of cards released to production that deliver value
Rework = Number of technical debt and defect cards in inventory and work-in-process

I’ve pushed various teams’ data through and the charts seem to correlate with the events described in my historical notes. Here's a chart based on a small, experienced team working on a small project for 3 months.

Effectiveness
Originally uploaded by energizr

You can see there wasn't any throughput in the first 4 weeks as completed cards queued up in inventory. In week 5 that inventory was flushed to became throughput as the first cut was released. Effectiveness then varied with the weekly releases until week 10, which saw the team 100% effective with no rework cards in inventory or work-in-process. In week 12, however, effectiveness dropped to -33% because 1 technical debt card was work-in-process and 3 fixed defects were queued in inventory while only 3 cards were released.

Although it's perhaps a simplistic indicator do you think it's useful as a measure for effectiveness (i.e. a team's ability to deliver value and stay healthy)? Or is it utter tosh? Can it be refined (without complicating it)?

There's more to done than the green dot

2010-02-23T23:45:00.000Z

So you're working on a user story with your pair, developing vertical slices and getting feedback from the tester and customer as you progress. You're ticking off the acceptance criteria as they're satisfied by the emerging functionality. Awesome! Everything is tickety-boo. Then the customer realizes that something is missing and asks for that something to be incorporated into the card. What do you do?

You could just refuse and ask him to write a new story and prioritize it accordingly. You could say yes, have a discussion, write the new acceptance criteria on the back of the card and carry on. Some people say no because the additional work will exceed the original estimate for the story. Some people say no because they won't be able to finish the story with the new criteria by the showcase and the card will slop.

I used to say slop was bad. I stopped saying that some time ago when I started to focus on limiting work-in-process.

I can't say what the right thing to do is because situations are different. I do say that the discussion with the customer must happen so that everyone involved understands, quite simply, whether the story will make more sense for users and provide them with greater value if the additional something is included. Perhaps the customer is pushing his luck. Or maybe he's got a point.

I always say stories are an invitation to a conversation. In the last year we've started to frame these conversations in the context of users because we've been using iteration to explore interaction designs and improve user experiences. Given the users' perspective, I came to realize that stories are also a journey taken with the customer to explore options and learn more about users. It's easy to write acceptance criteria but it's difficult to express what user experience will really work until we see a few different ones (and ideally validate them with real users). As a result, I am seeing more conversations where the customer or designers want to add something to a story when it's in play. I believe this to be a good thing providing the discussion happens and everyone agrees that the resultant delivery will be better for users.

The goal is about users and satisfying their needs, delighting them if possible with every story delivered. There's context, a bigger picture, a system and that involves how the users interact with it. It's not about velocity, estimates or slop. And it's not about ticking off the acceptance criteria and getting the green dot. That's all just process.

Without accountability there can be no solidarity

2010-02-10T17:04:00.042Z

Over the past two years I've been seeing teams fail because people are not holding one another accountable. People tell me they are scared of being perceived to blame and so instead they say nothing. I asked some people why they don't hold people accountable. They responded with things like: "I'm really uncomfortable doing that." Or "I'm not good at saying that kind of stuff. I'm just a developer." And I empathize. I really do. I'm uncomfortable holding people accountable too. I'm guessing everyone probably is to some degree. And by the way, I possess those developer genes. That said, I still think these responses are phooey! Being able to communicate is a basic human skill. We all do it, admittedly some better than others, but just because something is difficult doesn't mean we should stop doing it. How will we learn if we don't practice?

Saying nothing rather than speaking up is the worst thing we could do. I see two reasons why. First, everyone has missed a great opportunity to learn something. If something goes wrong, and it does - often - then those accountable are expected to discuss their part in the events, because their knowledge is needed to improve the way we work. And second, restraint leads to pent-up frustration, even anger. Over time, perhaps bickering starts and fissures appear in the team. People start talking about others behind their backs, which really is blaming, and eventually what we've held back for so long probably comes blurting out in a damaging way.

So what's really stopping people holding others accountable? Is it just a misunderstanding of the difference between blame and accountability? This is something I'm struggling with.

To be accountable means to accept responsibility and be answerable for any actions or decisions. However, to be blamed is to be assigned responsibility for a fault in a way that deserves censure. But this still doesn't make it clear for me. I like to think the difference between accountability and blame is in the intent. Think of accountability as a handshake between people whereas blame goes in one direction.

The intention of holding people accountable is to understand, with them, the nature of the failure, its context and how it came to be. Those people questioning the actions value the participation of those responsible for the actions because they have useful information. And together they achieve clarity to explore solutions so that everyone may work to prevent similar failures in the future. The sole intent of blaming people is to identify the culprits and impose punishment. There is unwillingness to engage in a collaborative and objective analysis of the events. Instead judgment has already been passed based on a personal interpretation of events.

I think fearing accountability and staying silent perpetuates the very thing people are seeking to avoid - blame. Holding people accountable is not optional. We need to take it easy and be gentle but we must start holding people accountable. We shouldn't overreact to peoples' reactions. They may feel like they are being blamed based on their past experiences, so we must work extra hard to communicate our intentions as positive and constructive framed within the context of learning. And we must keep at it. Eventually the blame-free culture of accountability we thought we had will emerge for real in a healthier team with a new found honesty and integrity.

PS. I'd be really interested to hear your thoughts on this subject and any stories you have to tell. I still seek to understand this notion of accountability better.

Sitemap on the wall

2010-02-04T23:02:00.001Z

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.009Z

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 time, usually 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 X. That amount is submitted, consolidated and rolled up into department, division and ultimately company figures, undergoing a protracted review process en route 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 submitter, 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 reviewers know this. And the submitter knows the reviewers know and .. sigh. What starts out involving the operational realities soon becomes a purely financial planning exercise that is divorced from those 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.