I’ll occasionally listen to Vasco Duarte’s podcast, Scrum Master Toolbox. The most recent episode had Bas Vodde, co-founder fo the Large Scale Scrum framework (organizational design!). It’s a great introduction to the opinions and assumptions that underly any large organizational transformation attempt. Listen to the podcast online, well worth the time.
Creative Selection is a recently published book by one of the developers involved in the original iPhone program offers good insight into how Apple was able to bring to market a game-changing device. This is all from the vantage point of one the developers, not an executive. This view offers some unique insight into how a large scale product development effort can work – and in this case, work exceptionally successfully. I was particularly interested in the ways the process at Apple mirrored some of the best research-backed advice about how to manage product development. Going thru a large scale Agile transformation now, I found the parallels to advice in frameworks such as LeSS comforting.
“Every day at Apple was like going to school, a design-focused, high-tech, product-creation university, an immersion program where the next exam was always around the corner.”
A commitment to learning is so rare in most companies in my experience; the idea that a developer takes on a role that he has no knowledge of and “figures it out” with the help of other talented folks. The company trusts him to learn and adapt – and with an iterative process, this allows for check-ins to course correct. The developer must also be open to suggestions – even with deep feelings about the work done. The point is the product – move the product forward.
This is so obvious on one level and yet so incredibly difficult to implement in practice. The work of leading a group of people in this fashion is much more difficult than the standard big business management approach of making up deadlines and metrics and acting as if the management is separate from the process. Leaders are great at fooling themselves that it’s their genius that got them to the position they hold – one has to continually be on guard for this internal monologue and beat it back. Sadly, few leaders seem to be on active guard against this.
“The culture we created is inseparable from the products we created. In my experience, this manner of culture formation works best when the groups and teams remain small when the interpersonal interactions are habitual and rich rather than occasional and fleeting. The teams for the projects I’ve described in this book were small indeed. Ten people edited code on the Safari project before we made the initial beta announcement of the software, and twenty-five people are listed as inventors on the ‘949 patent for the iPhone.”
The default direction in most large enterprises is to either increase team size to add every little specialist’s role or split up work into smaller and smaller specialties (or both). The more I’m exposed to the issues of dealing with large teams and specialists groups the more the advice to target small teams of cross-functional people makes so much sense. In short, always move to simplify the organization. Added complexity will trick you into thinking you’ve solved a problem when in reality you are setting the stage for additional problems. Apple understood this, tellingly even in a project like the iPhone where it would have been the default step to create very large specialists teams.
“There are innumerable ways creative selection can become bogged
down,since this working method must be applied consistently over some time to yield results. Consequently, our success was as much about what we didn’t do as what we did. Mostly we avoided falling into any of the typical product development traps common in Silicon Valley and that, I expect, occur often other kinds of creative organizations and businesses. “
Among the things that they didn’t do are long discussions about products devoid of concrete examples that force a grounding in reality. They avoided using artifacts that were separate from the actual work – things like requirements or paper mockups.
Perhaps most importantly they didn’t have senior managers involved in decisions which weren’t personally engaged in the work. This is the root problem of management in some ways. The idea that they can be disconnected from he work and yet dictate, in the most disruptive way possible how the work is done. Continuously changing direction and causing confusions – but never changing the made-up deadlines they believe will push people to perform. It’s so perverse you’d think it was designed on purpose to hinder performance.
They didn’t set-up special research departments separate from the teams doing the work. Most companies have such little faith in their front line technical people. For some reason, there is this belief in hiring “special people” to do the interesting work. Think for a second about this. The same people who best understand how your systems work, best understand your customers are getting the shaft because you’re saying that they are incompetent to do the interesting work building the future. Set aside the fact that often when a company creates these special groups, they’re staffed with people who are better at selling themselves than doing work.
“At Apple, we built out work on this basic fact. Demos made us react, and the reactions were essential. Direct feedback on one demo provided the impetus to transform it into the next. Demos were the catalyst for creative decisions.”
Similar to a Sprint Review in Scrum – an opportunity for the team to show the work and gather valuable feedback that will inform the priority of the Product Owner and also what the team focuses on in future sprints. No matter the organizational model, a company, uses, this quick feedback is so critical and yet so rare.
“Scott took the chair at the long wooden table in Between, a Wallaby prototype tethered to a Mac lying on the desk. Scott picked up the Wallaby, and as he started each demo on offer in the switcher app, the programmer who created the demo stepped forward to describe how it functioned. These how-to instructions could be complicated. Some involved blue-sky interaction models, like one collogues’s complex multiple-tap scheme built around a few super-big Kays he could type on without looking. Others called for various orchestrations of multitouch input s to type letters, enter punctuation, and capitalize words. Scot was game to try everyone, and as always, he was upbeat and encouraging. He found something positive to say about each demo — good graphics, clever idea, interesting concept — but he was still having a difficult time. None of the keyboards offered quick and accurate typing.”
Perhaps the most exciting point in the book for me is here you have a prototypical technology leader – not someone who’s apt to be a pushover, and yet in this context, he was sure not to crush the morale of the developers. Even in the case of a keyboard, a do or die aspect of the phone, he was still careful to provide praise where he could and not fly off the handle that the team hadn’t solved this critical problem.
Creative Selection is an engaging, quick read. Highly recommended for anyone who’s interested in how the most successful consumer product in decades came to be. There are great lessons here for anyone dealing in a complex environment. Apple wasn’t perfect in any sense, but it sure does seem like they got some things right about complex development. Things that many if not most companies get entirely wrong.
Pop-Up Café In Tokyo Will Allow Severely Disabled to Work Using Robotic Avatars | Spoon & Tamago
— Read on www.spoon-tamago.com/2018/11/08/pop-up-cafe-in-tokyo-will-allow-severely-disabled-to-work-using-robotic-avatars/
Given all the doom and gloom around increased automation displacing large segments of the workforce, this is a feel-good story about how robotics can help members of society.
The state news agency Xinhua says the nameless presenter will help reduce news production costs.
— Read on www.bbc.com/news/technology-46136504
Yikes! This is just about as creepy a thing as I’ve seen in a long time.
An enormous amount of time is wasted in e-mail. In my experience, much of it is driven by people at work who see no issue with penning short e-mail questions that take them 10 seconds to craft and send but require the recipient to spend hours responding. I usually just ignore these.
The long wind down of Theranos is coming to a conclusion. Now the criminal case must proceed against the perpetrators of this fraud.
Have you hired people whom you think will not do the right thing unless you give them a bonus?
When the subject of bonus payments based on some measure comes up, and I push back against the concept I often hear the refrain that if we don’t bonus people to achieve a specific metric, they won’t push to achieve it.
Let’s flip this on its head and see how it sounds. Do we have people who will refuse to do a good job, refuse to do the right thing, unless it’s tied to some extra payment? If this is true are these the types of people we want? Mercenaries who will only fight for our customers, the company and their team when there is a stack of cash attached? A transactional relationship?
This type of employee isn’t what most people think of when they think of a well-performing employee or a great teammate is it?
I often hear objections when introducing new organizational concepts such as Agile to a management group. Things like a lack of “accountability” or “strategic thinking” on the part of the employees. The employees, they say, cannot work in a self-managed way. Chaos will ensue or something to that effect.
One question I’m fond of asking is “who exactly hired these people?” Isn’t management admitting its failure? They’ve failed by making poor hiring decisions. They’ve failed by not mentoring and growing the skill of their people. The bottom line is that even if everything these managers say comes to pass the first place I’m looking for a cause is the managers.
True, the structure is also a major driver of the problem and managers, especially mid-level managers are often operating in the environment created by those higher up the ladder. I also know that too often mid-level managers use that as an excuse for lack of leadership. They may have much room for maneuver within there groups. The high ups can’t watch everything after all.
Managers, even those in a toxic environment, assuming they choose to stay in that environment, should start asking what they can do to improve the situation rather than using the structure as an excuse.
This short video interview of Andy Hertzfeld is interesting from a purely historical context but it also gives a glimpse into how hardware and software engineers worked at the dawn of the personal computer revolution. It will sound familiar to anyone doing development today in an iterative fashion – no matter the specific framework.
One of the most exciting stories in the piece is about mouse acceleration. This feature is something so fundamental to the experience of using a GUI but not evident at the start. Putting work out in the world and seeing how it feels is the only way to detect these things.
The idea that D.C. has more psychopaths per square meter than any other place in America is something I can buy. It’s also the best reason I can think of to support smaller government.