Chris Hartjes – Why Don't You Trust Your Developers?:
“For most of my career, the reality has been that developers sit there in an open concept office with music being piped into their ears so that people won’t distract them so they can get some fucking work done. Every meeting, every random conversation, every interruption as their boss decides today’s the day we start working on his favourite feature is a barrier to getting work done.”
Wed, 20 Jun 2012 21:36:28 +0200
Fri, 15 Jun 2012 10:03:17 +0200
Gerry McGovern at CMSWire – Web Experience: Designing for the Obvious, the Boring, the "Of Course":
“Often, making it easy for the customer means doing lots of boring, behind the scenes work. For example, you can make your search work much better by deleting old content. But that's the type of work nobody really wants to do.
[…] "Great design means that one look and the end user reacts by knowing what to do with a knob or a button, without as much as even thinking about it," Om Malik writes. "Of course this knob is what turns the volume up, or brings up the home screen. This "of course" factor is at the heart of every great design."
Fri, 15 Jun 2012 09:52:10 +0200
Matthew Heusser at CIO.com – How to Advance Lean Software Development (Beyond the 'Toyota Way'):
“Lean manufacturing focuses on delivering one part, end-to-end. This is sometimes called one-piece flow. […] To get to one-piece flow, we'll eliminate multi-tasking.
[…] Instead of "pushing" work to the next step in the chain, we pull it. This means testers don't take on work until they are ready for it. […] [The programmers] have to figure out how to help the testers— by testing themselves, perhaps, or by writing test tools or "drivers."
[…] The lean software solution is to get the person who can answer the question in the room—either by embedding the customer directly in the team room, or, for a technical question, pairing new programmers with more experienced staff so they dont get stuck.
[…] When I started at one recent client, the team was doing "book" Scrum, with two-week iterations and bi-weekly ritual meetings that included retrospective, planning and estimating meetings. These meetings often felt forced and artificial. […] We dropped iterations and moved the meetings to a just-in-time format. […] Since we made that switch, two other teams switched to this continuous flow approach; three other teams continue to use iterations. There was no mandate from management or standard to follow. Certain teams simply saw waste and wanted to eliminate it.”
Mon, 11 Jun 2012 09:05:36 +0200
My favourite quotes from the Wikipedia page on W. Edwards Deming:
“[Deming] is regarded as having had more impact upon Japanese manufacturing and business than any other individual not of Japanese heritage.
[…] Deming questioned the company's culture and the way its managers operated. To Ford's surprise, Deming talked not about quality but about management. He told Ford that management actions were responsible for 85% of all problems in developing better cars.
[…] When people and organizations focus primarily on quality, quality tends to increase and costs fall over time. However, when people and organizations focus primarily on costs, costs tend to rise and quality declines over time.
[…] Eliminate the need for massive inspection by building quality into the product in the first place.
[…] Break down barriers between departments. People in research, design, sales, and production must work as a team, in order to foresee problems of production and usage that may be encountered with the product or service.
[…] Eliminate management by objective. Eliminate management by numbers and numerical goals. Instead substitute with leadership.
[…] Obstacles: Placing blame on workforces who are only responsible for 15% of mistakes where the system designed by management is responsible for 85% of the unintended consequences.”
Fri, 08 Jun 2012 11:48:43 +0200
Alan G. Carter’s The Programmer’s Stone – Implications for Software Engineers:
“The clerical worker, by subjecting the programmer to bureaucratic stress, has forced the programmer into stress modulated focussed attention, and the ability of his or her brain to hold the program that is already there is lost. Hence “evaporation”. In some organizations it’s quite common for people to suffer this repeatedly, day after day, such that a week goes by with no useful progress - and at the end of it the programmer has suffered aversion therapy such that they start flinch away from trying to load the problem up again.”
Fri, 08 Jun 2012 11:43:03 +0200
Donald Reinertsen and Stefan Thomke at Harvard Business Review – Customers Don't Want More Features:
“Determining which features to omit is just as important as—and perhaps more important than—figuring out which ones to include. Unfortunately, many companies, in an effort to be innovative, throw in every possible bell and whistle without fully considering important factors such as the value to customers and ease of use. When such companies do omit some planned functionality, it's typically because they need to cut costs or have fallen behind schedule or because the team has failed in some other way.
Instead, managers should focus on figuring out whether the deletion of any proposed feature might improve a particular product and allow the team to concentrate on things that truly heighten the overall customer experience.”
Fri, 08 Jun 2012 11:27:47 +0200
Fri, 08 Jun 2012 11:13:59 +0200
Occupy Meeting: “Death By PowerPoint, Resurrection By Tablet is a manifesto for a new, more substantial workplace. Stop meeting after the meeting.”
Quotes from the manifesto:
“Research shows that individuals create best in solitude and isolation. Committees and meetings do not create. Their role is to serve as mediums of dissent and contention.
Great meetings are gladiatorial arenas where ideas conceived in isolation can do battle. In this war, data is the primary weapon. The tablet can be the ubiquitous window into the world of data.
[…] Empowerment in the sense of permission is a meaningless word to the maker. Meaningful empowerment means resources.”
(Via CMS Wire.)
Sat, 02 Jun 2012 23:22:16 +0200
Gojko Adzic – How To Solve “Not Enough Time”:
“Teams track velocity as story points, number of items implemented. Instead, we should be tracking value delivered. That is the real velocity. That is the real outcome. Any improvement to the software delivery process should speed up the rate with which we deliver value, not effort.”
Fri, 01 Jun 2012 09:45:49 +0200
Matthias Marschall (in 2011) – The three essentials of any agile process:
“By making progress (and bottlenecks) visible, helping people focus, and pulling together as a team, everyone starts to be proud of what they’re doing. Suddenly, they want to be responsible for the whole story (not just an implementation detail). They start to take pride in delivering perfectly working features. Congratulations, you’ve reached the ultimate goal of agile: Your team takes ownership!”
Fri, 01 Jun 2012 09:43:15 +0200